On Sep 26, P T Withington wrote: > So why does the object-valued-attributes-get-magically-merged loop not > cover this case? Because that loop merges default attributes with instance attributes. UserClass makes the admittedly arbitrary distinction that values which do not have setters get put on the prototype, instead of in defaultattrs. This tends to work in practice, but it isn't crisp.
> Does this loop actually work? I'm pretty sure. It'd be a fairly simple matter to print out the things that that loop works on. > What attributes is it expected to work on? Hm. I see there are two > instances of this loop, one in LzNode and one in LzUserClass. In the > latter, you only enter that loop if there is a setter associated with > the attribute. But, if there is a setter associated with that > attribute, why does the setter not just handle this magic merge? There is *no* setter for the options attribute. I guess there needs to be one in your new code. > In Legal's, we explicitly ensure that the dictionaries: setters, > getters, defaultattrs, __LZdelayedSetters, and earlySetters are > inherited from the superclass using a private dictionary (so the > subclass won't clobber the superclass's dictionary). And, if an > instance defines a setter, we ensure that it makes a private dictionary > first. But this is not the case for these other inherited dictionaries. > I guess getters aren't really used any more, and these other things are > internal-only so instances would not be adding to them? It seems to me > that options should be handled just as setters are. Agree. > And perhaps the object-valued-attributes-get-magically-merged loop > should be retired, since it does not seem to really do what we expect? Also agreed. It seems worthwhile to run trunk with that loop with instrumentation to print out the things that it works on so that we consider each individually. > Or maybe you could explain to me what is really supposed to happen here? > I'm having a hard time figuring out what the semantics are supposed to > be just from unwinding the code... Well it's not like there's some grand design that is simply not documented. The spirit is to make instances behave like classes, and that loop is supposed to be a general way to effect this. There are a few places where the presence of a setter has overloaded meaning. One is this behavior with respect to the putting attribute values on the prototype, which leads to the merging of attribute definitions. Another is in states, where slots for which the state has a setter are captured by the state, rather than applied to state's target. I'm not saying that this good design, but it tends to work in practice. A _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
