It's definitely not being cast off... Just scrutinized :-)
From: "Dan Webb" <[EMAIL PROTECTED]>
Sent: 5/10/2007 11:52 AM
Subject: [Prototype-core] Re: Class.create() and method binding
> No, seriously - how often do people copy instance methods around? Is the
> minority really enough to justify the mass binding on each instance
> creation? How about solving the problem in a real way, by realizing what
> you're doing an compensating for that:
> func = a.showA.bind(a)
People do copy methods around without knowing it all the time: when
assigning event handlers and using the enumerable methods most notably
and this always causes confusion. Perhaps I didn't give real enough
examples. MANY people try to do things like this and get very
var w = new MyWidget();
then find that this has changed in the context of the event handler.
This is by no means an edge case: It happens all the time. Even when
you know that this is the case and know about bind() it get really
ugly as you find lots of places where you need bind and this would
clean up a lot of those.
My main point is that Class.create() does not create what anyone
thinks of as a class. It's sort of looks like one but doesn't do
anything that classes do. Why not make it behave more like a class?
In Java, Ruby and just about all class-based languages methods have a
binding to their instance. This would be mimicking that behavior.
Plus, if you want the unbound version of the method you can get it
from the prototype.
I really don't think it's such a bad idea and I'm slightly surprised
that you immediately cast it off.
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