Sorry, Colin. I wish I could put a ton of stuff like this up on my blog (which is basically not even a blog, for total lack of time)... We're busy with client projects and launching a startup...
I for one, don't find it all that cumbersome to create my handles/observe during init, and then stop observing and set the handles to null during dispose. But I do know what you're getting at. And to answer your statement "...your GC class has nothing to do with events specifically". That's what I was trying to get at with the subclassing. My point was exactly this: the GC class is completely generic, specific details left to subclass implementations. What's to stop you now from creating a very light wrapper around proto's Event.observe/stopObserving, implement a custom EventGC class, and make it work without requiring this potentially laborious exercise of trying to modify the core, which for all intents and purposes works just fine for the majority of cases? I'm not trying to say to stop trying to get it in there (as others may completely agree with you and its value)... just that you seem to be a little bit defeated thinking you can't currently achieve what you want without the core being modified. Hmm.. okok... I'll take some time to put together a simple example... give me a few hours to catch up on some stuff. On 2/26/07, Colin Mollenhour <[EMAIL PROTECTED]> wrote: > > > That's just it, I don't fully understand how your GC class is supposed > to work so I was hoping to see a real-world usage example, but if you > are too busy I can understand that completely (maybe you have a page > up already that you could provide a link to?). I think your focus is > on scalability and performance, and while I do consider those things > important, my focus is really more on making *event* cleanup easier by > requiring fewer lines of code and providing a hassle-free way of > queuing up event handlers to be disposed of correctly. I appreciate > your help and suggestions but from what I understand your GC class has > nothing to do with events specifically. I would probably have given up > by now on getting this added to Prototype if it weren't for the tight > coupling of events and caching in Prototype's current system. If these > were at least separated then I could add EventCache on top of > Prototype but they are not at all so that would currently require > overriding pretty much the entire Event class. > > Just from a modular code design standpoint, can we all not agree that > event handler methods and event handler caching are better off > separated to a certain degree? I'm not suggesting a new API, just a > new caching class that gives the user more control over caching when > they want it. Instead of having one huge cache for every event, I am > proposing the default cache (Event) and then a class for creating new > caches to make cleanup by the user easier. Am I asking too much or am > I just going crazy? > > Thanks, > Colin > > > > > -- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
