Dan Webb wrote:
> > It's not a bad cause, I just think the solution is a performance eater.
> > Imagine: the loop runs on every object instantiation. It wraps every
> > function inside another and it needs $A for that. After that, every function
> > call internally calls another, triggering $A one more time. To me it's a
> > terrible waste considering the total number of objects and their respective
> > instance method calls. And for what, solving event handling gotchas? Surely
> > we could do some implicit binding only in places where it makes sense (for
> > instance in the Event or Ajax modules for some operations).
> Yeah, your right on that point. It was my main concern. It could be
> streamlined a fair bit though (getting rid of $A would be fine) and I
> wondered how many classes that are created with Class.create() really
> get instantiated in a typical project. I'm interested to see the
> impact it does have...I'll write some tests. I think you're right
> though, it's probably not going to be worth the performance hit.
> Saying that, I use base.js quite a bit which wraps functions in quite
> a bit of code and I've not noticed the performance hit.
My objection is not the performance hit -- it's violation of POLS.
(Even though I do feel the pain this is meant to address.)
The refurbished system in the events branch corrects scope
automatically in IE, so that "this" refers to the element that
received the action. This means that calling
Event.observe(someElement, 'click', foo);
(where foo is a function) would fire the event in someElement's scope,
Event.observe(someElement, 'click', Foo.bar);
(where bar is a function) would fire the event in Foo's scope.
I think that events firing in class scope should remain opt-in,
whether through the existing `bind`:
Event.observe(someElement, 'click', Foo.bar.bind(Foo));
or through an extra argument:
Event.observe(someElement, 'click', Foo.bar, Foo);
I prefer the latter, since it'd deprecate the useCapture argument
(which won't work in IE, so we shouldn't expose it).
(though this will change for classes in ES4). I think we'd be stepping
into a minefield if we introduced new "magic" conventions for what
"this" means on any given line of code. It's hard enough to keep track
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at