very basic listbox code request for comments

[Timmy Douglas]

Brian Rice <water at tunes.org> writes:

> On May 16, 2006, at 12:10 PM, Timmy Douglas wrote:
>> Brian Rice <water at tunes.org> writes:
>>
>>> Changing delegation dynamically is too powerful and should only be
>>> done when it's been thought through in a pattern (such as the
>>> Morphic dynamic mixins code).
>>
>> I think this behavior sort of makes sense with users manually
>> overriding defaults in the themes here. Then, to change the default
>> color (etc) you just modify one value (in the top class), and since
>> the non-overriden objects all point to it, you don't have to do any
>> propagation down the line. To restore the default setting, you just
>> remove the slot in your object you overrode it in, and it points back
>> to the default.
>
> 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.


Did that darcs send command send anything? I guess I'll try
unrecording and fixing some stuff up before I send again.