Interesting. The new class substrate does something very similar: it has both an instance initializer and a class initializer and the class initializer is called on the class prototype. In the class substrate, the class initializer is called with this bound to the class that it is the initializer for and the prototype is passed as an argument. The class initializer(s) are invoked from least- to most-specific for each subclass. I'm not saying this is the right way to do it, just that's what happens currently. It seems 6/1 whether the class or the prototype is this and the other the argument. I'm loathe to waste a prototype slot pointing back to the class if I don't have to since it's just one more name taken from the user.
On 2006-08-22, at 14:51 EDT, Adam Wolff wrote: > I am generating classes at runtime to represent objects whose > schema is > delivered by the server after my app starts. > > I want to encapsulate the procedures that statically initialize one of > these classes. I have been doing this by calling them directly on the > class prototype. The code looks nice because I can just say > "this.foo = bar" and it has the effect of setting it statically. It > has > the additional advantage of allowing me to take advantage of OOP > features > for these static initializers. > > There are cases where the static initializer wants to insert its > *class* > into, say, global named lookup directory, so that other elements > can find > it. > > Of course, the caller of the static initializer could always pass > in the > class, but that seems bulky. > > A > > On Aug 22, P T Withington wrote: > >> Can I ask what you are really trying to do? How did you come upon >> a class >> prototype and not have the class? >> >> On 2006-08-22, at 14:13 EDT, Adam Wolff wrote: >> >>> I have a reference to a class prototype, but not necessarily the >>> class function itself. Is there a JS approved way to do get this? >>> I don't >>> have an instance of the class (or I could look at its constructor.) >>> >>> There's a comment in the openlaszlo trunk version of lfc/core/ >>> LzClass.as >>> that says: >>> // same as <instance>.__proto__.constructor >>> // or <instance>.__constructor__ in swf7 >>> // included for backward compatibility >>> constructorF.prototype.class = constructorF; >>> >>> But this isn't true for the prototype itself -- the constructor >>> of the >>> prototype is unrelated in trunk, and it's a reference to the >>> superclass >>> in Legals. >>> >>> I can use myproto.class in trunk. Is there a similar thing in >>> Legals? If >>> not, I guess this is a feature request. >>> >>> A >>> >>> _______________________________________________ >>> Laszlo-user mailing list >>> [email protected] >>> http://www.openlaszlo.org/mailman/listinfo/laszlo-user >> _______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
