very basic listbox code request for comments

[Brian Rice]

On May 14, 2006, at 12:46 PM, Timmy Douglas wrote:

> Brian Rice <water at tunes.org> writes:
>
>> That's the reason for "cascade" in the CSS acronym: so that separate
>> stages of styling can be grouped and updated separately.
>>
>> How this is worked out on a technical level with a live-object
>> environment is up to your imagination, and implies some overhead to
>> track the styles and recompose, but this doesn't seem like a heavy
>> price.
>
> it seems like #addDynamicSlot: could take care of this, except I'm not
> sure if there is a way to "re-point" things back to the original
> object after you call #addSlot: on one of the children (would just
> removing it work?). I don't want to go ahead and write code when there
> might already be a language feature to do it.

There isn't a feature for that (removing an addDynamicSlot: override)  
except to call #removeSlot: which would work, BUT that assumes that  
you know on which object that override slot was made.

> But this part of it doesn't make sense root.slate (L525):
>
> x@(Root traits) addDynamicSlot: slotName valued: val
> "This creates a `dynamic slot', which means an immutable delegated  
> slot
> that can be overridden from its default per object, making an  
> effective
> customization policy.
> It works by ensuring that the object has a slot of that name with  
> that value,
> and finally defining a mutator method on it to define a new slot on  
> the
> *receiver* when mutations are attempted."
> [
>   x addImmutableSlot: slotName valued: val.
>
>
> " why not addImmutableDelegate? "

Do you want to delegate to the value 4 when you merely want it to be  
an overrideable default value? There's no case I can think of where  
you'd want to override a delegation dynamically using a mutator method.

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).

>   [| :obj :val | obj addSlot: slotName valued: val]
>     asMethod: (x mutatorNameFor: slotName)
>     on: {x. NoRole}.
>   x
> ].

> When I tried copying and pasting that code and making the change in
> theme.slate, then loading it, but I got weird errors later in ui.slate
> where:

Why did you have to load that code into Slate when you made no change  
to it and it is already in the standard image?

> Debug [0..1]: lobby mainWindow.
> -2.000009
>
> etc. it seemed like the constructor functions returned the correct
> objects but somewhere along the line things got corrupted?

I need something more concrete that I can debug - a smaller, tighter  
test case.

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060516/8c6b0567/PGP.pgp