very basic listbox code request for comments
Timmy Douglas
timmy+slate at cc.gatech.edu
Tue May 16 17:58:43 PDT 2006
Brian Rice <water at tunes.org> writes:
> On May 16, 2006, at 1:38 PM, Timmy Douglas wrote:
>
>> Brian Rice <water at tunes.org> writes:
>>> I think you don't understand what what your change does. Let me
>>> explain:
>>>
>>> When you use #addImmutableDelegate:valued: in that code, you make the
>>> HOLDER of the new slot inherit from the VALUE you're putting in that
>>> overridable slot. In this paragraph, however, you're talking about
>>> wanting to delegate from some other object to the HOLDER of the slot,
>>> and this is what #addDynamicSlot:valued: is for.
>>
>> Ok, yeah, I totally misunderstood what delegate slots were
>> for. Somehow I thought these were the slots that were inherited (only
>> exist in the base object) while the data slots got copied (into
>> another memory location) into the child object everytime you used
>> #define:&parents:. Thanks for clearing this up.
>
> Whew, I'm glad that was all the confusion was about. Incidentally, I
> should re-iterate that I am not entirely happy with the way Slate
> handles inheritance; that basically we have been working from the
> Self model and customizing it as we go.
ok, well things have become a lot clearer. thanks
> However, "darcs send -o" will make a file with the patches in it
> which you can manually attach, and that's usually what I recommend/use.
ok thanks.
it seems something like:
newObj: se derive &mixins: themeObjects
puts the parser in a loop for me. I added parens to fix it:
newObj: (se derive &mixins: themeObjects)
not sure where bugs like this should go... maybe I can get the
listbox/theme thing working tonight.
More information about the Slate
mailing list