Not sure how you are using the word "trait" here. It has come to have a fairly exact definition in computer science. We used it loosely to describe a proposal that would allow you to write a class whose properties could be added to more than one other class, and decided the more accurate name to use was `mixin`.
LZX supports `mixin`, although it is not yet documented. There is an example of the usage of mixins available here: http://svn.openlaszlo.org/openlaszlo/trunk/test/mixins.lzx But here's where I'm missing what you are getting at. If I am going to dynamically create a listener, I think the first thing I have to know is "What am I listening for?" If I don't know the name of the thing I am listening for, how can I listen to it? So, it seems to me that the sender needs to first publicize in some way the names of the things that they are going to send, and that that would mean they would need to declare those names. I look forward to seeing a concrete example. On 2009-11-15, at 15:04, jamesr wrote: > Dynamically creating listeners (on a parent) is nescessary for the traits > pattern i currently use, and there is no substitute; either it's done this > way, or the actual laszlo traits subsystem is revived (yay! i had this in > pyroglyph) where any number of classes can be specified, comma seperated, in > a traits attribute where each of the children of the class (not any variables > on the trait-class-source) are added to the traited class. We don't have this > yet, so in that light i must mention that it is not a case of bad design. > Dynamically creating handlers and listeners is essential in using laszlo > correctly, as i see it, and without it the benefits of working in javascript > is negated. I expect that kind of strictness in Objective-C, for instance, > but i want to be better then that; i'd like to see all dynamic opportunites > used when they improve upon how laszlo can be code-minimized and reusable. > I'm working diligently to get the traits file to where i want it to be (there > is ! just one little issue i want to explore about whenables and watchables) and then i'll have case studies to share and resolve with "you" (the list) > > Thanks for the links into the LFC btw! > > P T Withington wrote: >> On 2009-11-15, at 13:41, jamesr wrote: >> >> >>> Good Morning, I pulled two things out of the response that i wanted to >>> single out and discuss. >>> >>> *snip* >>> >>> You can't set an attribute that does not exist, so you have to declare the >>> attribute first. Just as you would have to declare the event first. The >>> same way you say: >>> >>> Actually, yes i can, and handlers fire too; this is a behavior i have >>> always assumed, relied on, and built into the patterns i use. If i use >>> setAttribute(a, b), the handlers for the event a will fire even if i >>> haven't declared "a". Have I misunderstood you? >>> >> >> If a tree falls in the forest and no one is around, does it make a noise? >> >> Yes, due to the dynamic nature of LZX, you can set an attribute that has not >> been declared on an instance. But I have to wonder: if you have not >> declared the attribute, how will anyone know to listen? It's just good >> programming practice to declare your attributes. >> >> >>> and >>> >>> *snip* >>> >>> If you want the latter behavior, you should be using events. That is their >>> contract. >>> >>> It is still the case of having a redundant pattern, not just speaking about >>> the constraint system. I would submit that the purpose of events and >>> attributes are intertwined and, apart from momentum, i don't see why you >>> would wire the system to have any care about it. >>> >> >> If all you have is a hammer, everything looks like a nail. >> >> There is enough flexibility in the constraint system that you can make it >> function as an event system, but as you have discovered, you have to subvert >> it by setting a new value each time in order to force it to send an event. >> >> We must be missing each other's point here. If I want an event, I would >> send an event, not use a constraint. >> >> >>> The entirety of my traits file, and other patterns i like, depend on the >>> above, so i'd like to be clear as we go on; i venture that the next file to >>> share will give us examples to speak of and rewrite "my way" and the "other >>> way" and see why i've figured there is such a big difference. >>> >> >> Looking forward to it.
