On 2006-03-14 14:47 EST, Jim Grandy wrote: > > On Mar 14, 2006, at 11:33 AM, P T Withington wrote: > >> Er, the call graph will tell you that sendEvent was called. I got >> the impression that what you are trying to get at here is to see >> _what_ event is being sent. The 'sender' of the event is an >> instance, and you might also be interested in which particular >> instance is sending the event. If so, you would want to add that, >> or not. It would be the difference between seeing that the >> 'onclick' event was sent and #button32.onclick was sent. Depends >> what level of detail you are looking for. >> > Right, my thinking was a little muddy. But still: I think knowing > the event dispatch frequency by name is more important than knowing > event/sender pair frequencies. The latter still has some > usefulness, though. Could I add a nested layer, so event/sender > wraps event? > > call #button32.onclick > call onclick > return onclick > return #button32.onclick > > Or would this be too verbose?
You're call. I don't know what you are looking for here. But you want the more specific 'call' inside the less specific, right? >> >> The trick here is that the sender may not have an id or name, so >> perhaps there will be no information there of use. If you look at >> _dbg_name in events, you will see that it uses formatToString, >> which preserves the object behind the string so you can inspect it >> even if it doesn't have a unique id. That connection will be lost >> in the profile log. (Clearly if you _do_ want to record the >> sender for profiling, convert the sender to a string once a >> registration time, not each time the event fires.) >> > Plus there's this. But the name as used in the constructor events > is still useful, and would work in this context as well. Debug.__String(sender) is a good compromise. >> >> Just to be clear, the reason for similar code in `mvn` is that it >> is the shared constructor for _all_ classes. It was pretty >> useless to see that in the call graph, what you really want to see >> is what class is getting constructed. Your change to sendEvent is >> similar in spirit, since _all_ events funnel through there, it >> doesn't give you any information about what events are used the most. >> >> I don't know if there is a pattern here we could exploit more >> generally, or if there are just a few methods that are like this >> that have to be customized to get useful profiling out of them. I >> guess anytime you see a method at the top of the profile list, you >> should think about whether it can be subdivided in this manner. > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
