Yikes. In Legal's, one of the Objects being 'merged' is toString! I have no clue what that does. But I can see how it happens: toString is a property of Object and it is not an Array, so the merge loop takes the path where it tries to make toString into an inherited hash...
On 2006-09-26, at 11:33 EDT, Adam Wolff wrote: > 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
