Method Pointers
Filip Dreger
fdreger at gmail.com
Mon Feb 27 03:03:21 PST 2012
> I think that this lack of equality is a shame, because
>
> 1) other languages have dealt with this without this level of confusion.
I don't think so - there is always a lot of confusion (partially
because in other languages many people use closures and very few
actually understand or even notice them). Take this Javascript
example:
function Clazz(x){
this.x = x;
}
Clazz.prototype = {
test: function() { alert(this.x) }
}
a = new Clazz(1)
b = new Clazz(2)
alert(a.test === b.test) // shows true
We have two methods on two different objects, and yet they are equal.
You might think that this is because "this" reference is not bound in
JS, but there you go:
function close_over(x){
return function(){alert(x)}
}
var example = {}
a = close_over(example)
b = close_over(example)
alert(a===b) // shows false
We have two instances of the same function with two equal closures,
and they are NOT equal. I believe that the latter piece of code
exactly mirrors your Java example (only in Java you would close over
"this", not over "example").
What I wanted to say is that - in my opinion:
- there is no "good solution that other languages use",
- even Javascript, the language that embraces event-driven
programming to the fullest, would not allow you to add and remove
listeners as in your use case,
- there is no point in paying a huge penalty (in terms of
performance) for a doubtful gain.
On the other hand, I really like Howard's proposition of comparing
lambdas by checking equity of each captured value. If I understand
correctly, it seems that a proper equals() method could be generated
without any runtime costs, and this could lead to some interesting
possibilities, like having two equal lambdas that are not the same
object.
The only problem I can think of is if someone had objects that - at
the same time - can listen to events, and require some sort of equity
(likely because of some external library).
A contrived example
- I use JPA entities in a project,
- In my JPA classes I override equals() to use the primary key (many
people do it),
- Now I try to observe some object that is global to the whole
application (or, actually, any scope wider than my current
transaction, it could as well be session or conversation scoped),
- Suddenly I run into all kinds of strange problems, because all
listeners created by entities that represent the same table row are
treated as equal.
Hmmm. After writing it, I suddenly don't think the example is so
contrived after all.
Does anybody know how ActionScript 3 approaches this problem?
Regards,
Filip Dreger
More information about the lambda-dev
mailing list