A class can implement another class, so a selector on a class applies to a member that implements t…

A class can implement another class, so a selector on a class applies to a member that implements that class.
Committed: https://code.google.com/p/dart/source/detail?r=11516

[Søren Gjesse, 2012-08-29 11:55:45]

lgtm

[kasperl, 2012-08-29 11:57:36]

LGTM, but I think we can do better.

https://chromiumcodereview.appspot.com/10900023/diff/2001/lib/compiler/implem...
File lib/compiler/implementation/universe.dart (right):

https://chromiumcodereview.appspot.com/10900023/diff/2001/lib/compiler/implem...
lib/compiler/implementation/universe.dart:378: if
(other.implementsInterface(self) || other.isSubclassOf(self)) {
So this is essentially a subtype (not subclass) check? This is probably correct,
but I'm not sure it's optimal. I think we need to distinguish between two kinds
of typed selectors: One that is guaranteed to be invoked on a subclass of the
receiverType -- and one that can be invoked on any subtype of the receiverType. 

We can trivially use the subclass variant for calls on 'this' and in most cases
where we have concrete type information (here we can actually do better because
we know that it cannot even be a subclass), but for typed selectors introduced
because of data flow and 'is' checks we need the subtype variant.

Does that make sense?

https://chromiumcodereview.appspot.com/10900023/diff/2001/tests/language/tree...
File tests/language/tree_shake_typed_selector_test.dart (right):

https://chromiumcodereview.appspot.com/10900023/diff/2001/tests/language/tree...
tests/language/tree_shake_typed_selector_test.dart:8: factory A() {
Use => syntax?

[ngeoffray, 2012-08-29 12:13:50]

Thanks Soren and Kasper

https://chromiumcodereview.appspot.com/10900023/diff/2001/lib/compiler/implem...
File lib/compiler/implementation/universe.dart (right):

https://chromiumcodereview.appspot.com/10900023/diff/2001/lib/compiler/implem...
lib/compiler/implementation/universe.dart:378: if
(other.implementsInterface(self) || other.isSubclassOf(self)) {
On 2012/08/29 11:57:36, kasperl wrote:
> So this is essentially a subtype (not subclass) check? This is probably
correct,
> but I'm not sure it's optimal. I think we need to distinguish between two
kinds
> of typed selectors: One that is guaranteed to be invoked on a subclass of the
> receiverType -- and one that can be invoked on any subtype of the
receiverType. 
> 
> We can trivially use the subclass variant for calls on 'this' and in most
cases
> where we have concrete type information (here we can actually do better
because
> we know that it cannot even be a subclass), but for typed selectors introduced
> because of data flow and 'is' checks we need the subtype variant.
> 
> Does that make sense?

It does. I added another test to make sure we don't forget about this
optimization.

https://chromiumcodereview.appspot.com/10900023/diff/2001/tests/language/tree...
File tests/language/tree_shake_typed_selector_test.dart (right):

https://chromiumcodereview.appspot.com/10900023/diff/2001/tests/language/tree...
tests/language/tree_shake_typed_selector_test.dart:8: factory A() {
On 2012/08/29 11:57:36, kasperl wrote:
> Use => syntax?

Done.