On 2009-11-14, at 21:22, jamesr wrote: > Hello PT, good to have you to speak with, along with the rest of the list! > I'm happy to get questions this early, since you and Rami caught the hints > utils.lzx makes about the rest of the framework. I'll respond to Rami after > this. I've replied inline to your questions, below. > > P T Withington wrote: >> Thanks for making this available. >> >> Some thoughts: >> >> `shift` is definitely going to be faster than `reverse/push/reverse`. >> >> I'm pretty sure there is a built-in `isMouseOver` which also worries about >> visibility and clipping. If you stick with your version, remember that >> mouse-coords are 0-based, so comparison with width/height should be >> exclusive. >> > I would use it if i knew about it. I think there is; i didn't "trust" it > since i (being lazy in somethings) couldn't easily find the source that > comprises it to check. I appreciate the 0-base hint, that will be fixed.
This is supposed to be the beauty of open source. That you _can_ find the source and the source is the ultimate documentation. http://labs.openlaszlo.org/trunk-nightly/docs/reference/lz.view.html#LzView.prototype.isMouseOver http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/views/LaszloView.lzs >> If you are having trouble overriding in swf9, be sure you match the >> function's signature. All public LFC API's should be overrideable. If you >> find one that is not, please file a bug. >> > In this case, i wanted to have the same method name with a different > signature. I wanted to adveritse a Utils.animate() method to be used in all > animation scenarios, but it takes less/different information then the "real" > animate, thus i was cordoned into changing the name as a last recourse. I > found that out in the conversion to SWF9, and wouldn't mind knowing if it's > possible to do what i want (same method name, different signature). No, you cannot override a function with a different signature. AS3 is not C++. Unlike C++, most other O-O languages operate this way: a function signature defines a type and method dispatch is type-based. You can approximate overloading by using untyped arguments and the "rest" argument `...`. >> `copyArray` can be written very efficiently: `<array>.concat()` >> > noted to-be-fixed, thanks! some of this is from older projects, given, i'm > very happy to include all things like this since a goal is to use all the > most up-to-date patterns. >> Maybe you could file a bug about `bringToFront` not reordering subviews if >> that is important? >> > It is very important. Imagine i am trying to determine which view is on top > of another in absolute terms, so that i can decide in what order to evaluate > those views for whether the mouse is over it, ensuring proper z-depth-normal > responses. This runs the drag trait's entire ability, and it was something i > had to crack to enable it. <view> has a method `getDepthList` that returns the subviews in depth-order, but if it is important to maintain the order at all times, again, why not file an improvement request? >> The built-in `containsPt` includes something like your `absVisible` -- views >> that are not visible can't contain a point. Perhaps it should be broken out >> as a separate API? File an improvement request? >> > Stated another way, I think my issue is actually having these functions > at-hand and extendable, and illustrated somewhere i could find them. For me > it goes back to not being able to find javascript implemenations of laszlo > functions to learn from and feel confident about. I think that these > functions should live in user-space, so to speak, instead of being part of > the underlying language; ymmv/discuss? The source is open for all to see and there is no restriction on extending the LFC core classes. I'm not sure what you mean by "should live in user space"? Please, if you see a need, file an improvement request. One of the points of open source is that we all help each other improve the system we share. >> In `now`, if your purpose is to send events, why not actually send events >> (using `sendEvent`), rather than trying to outwit `setAttribute`? >> > There are a few reasons, pardon me if don't find them all in this email; i'm > recreating the line of reasoning that was gone through developing it. I > believe the base problem is that i cannot declare events that will respond > just-like-attributes (e.g. handlers are recognized and set up for use) > dynamically. In this sense, setAttribute(x, v?) will always cause handlers to > fire, while sendEvent will only work if there is indeed an event declared. Am > I wrong? 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: <attribute name="myAttribute" ... /> to declare a property of a class or instance before you can write `setAttribute('myAttribute', ...)` you say: <event name="myEvent" /> to declare an event of a class or instance before you can write `myEvent.sendEvent(...)`. > Ah, yes i remember, there is a second, more important reason too. It is based > in computer science, but may be subject to opinion. I have a strong one in > this regard. > > I would like to show that the linkage between "attribute-event-handler" is > not casual and that events, while perhaps being a "glue" to make the > connection between attributes and handlers work, do not have a place in > user-space code. I would like to show that they override the > already-abstracted pattern that attribute-handler provides and are redundant > to use, i.e. they work against a fundamental pattern in Laszlo. It is my > belief that the event subsystem, while perhaps necessary for the formulation > of the attribute-event-handler linkage, should remain behind the purer > abstraction that the attribute-handler linkage provides. A further > conversation on this topic involves discussions of state and the meaning of > state in Laszlo. There are also developments in replication that obviate the > need to ignore duplicate states being passed around. Here's a little more: > > I've written my own "laszlo" runtime - not that i can call it that, but see > http://code.google.com/p/pyroglyph - and what i mean to illustrate is that is > that i've taken the laszlo philosophy and - IMHO - standardized it around > pseudo-code concepts that all "laszlo-like" runtimes could/should support. > The fallout from that potent learning experience is that having different > systems that perform the same asic function - causing handlers to run - is > unnecessary and doesn't enable additional features. In python, with it's > __setattr__ and __getattr__ hooks, you have no need to use setAttribute -- > all such attribute changes on a class fire handlers if there are any > (although there is a standard way to set it without calling handlers if speed > is important there). This worked very well - so well in fact that i did not > recreate the event system in my own runtime as it was never needed. In > essence, every time a declared attribute is updated, that is synonymous with > a state change -! - even if that change is to the same state. A state leading back to itself is fair game in state-machines, and it's fair game in laszlo, i figure. I'm having a hard time summoning the computer-science portion of this into well-worded paragraphs, so before I go to that length, would the list like to comment on why there is a need for independent state systems, i.e. why should i not conceptualize all algorithms that laszlo development requires through the lens of all attribute updates also being events? It's easier to teach and to read - while maintaining what is a truism for me - preferably there should be one clear way to promogulate state change through laszlo-land, and attributes being used and equated with events does that. Would anyone care to discuss somewhere it does not? I think you are talking about OpenLaszlo's "constraint" system (which is unusual but not unique in computer languages). The constraint system allows you to write "equations" on objects' properties and the system will ensure those equations are maintained. The underlying implementation of this system uses events. But just because one is built upon the other does not mean one is superior to the other. The constraint system is _only_ interested in maintaining the equations that constrain object attributes. If an attribute is updated, but does _not_ change in value, it cannot affect the value of any other attributes dependent on it. For this reason, the constraint system intentionally does _not_ send an event when an attribute value does not change. On the other hand, the event system is interested in handling asynchronous events. It allows you to attach handlers that will react _every_ time an event is sent. If you want the latter behavior, you should be using events. That is their contract. >> Looking forward to your next file. :) >> >> > Thank you, i'll be releasing my next file asap! > > .j.
