On 12/30/05, Nathan Derksen <[EMAIL PROTECTED]> wrote: > Those are equivalent syntaxes. Everything basically inherits from > Object, so this is valid syntax throughout, including your custom > classes. Basically, you are accessing (and apparently creating) > properties on the fly, with no type checking, and no compiler > validation as to whether the property being accessed actually exists.
while that is true, i thought that was what the "dynamic" keyword was to allow, and without it, you'd get some sort of error... > In many respects, LoadVars is doing what you want to do with your > Session class. well, in ways, yes - in ways, no. it's doing the same on-the-fly variable assignment, but doesn't have any other methods (like "addItem") that would put keys/values into a specific class member. it seems that LoadVars just iterates over the object and outputs any property it finds (which is why "onLoad=function" used to appear in LoadVars data). i was doing iterations over both the class object and the Items member. i'd obviously prefer just to have one place for all props. > Regarding number 2, that is what getters and setters are normally > for. With arbitrary properties, someone correct me if I am wrong, but > I don't think there is a way of intercepting them all, just specific > ones that you have defined. indeed there's none that i know of... but i've seen some folks do some strange things with Flash here ;-) as Jesse pointed out, __resolve won't work with variable assignments - so AFAIK, there's no nice way to handle this. g. -- weblog: broadcast.artificialcolors.com blazePDF: www.blazepdf.com band: www.cutratebox.com _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
