[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-jsr
Subject:    Re: [groovy-jsr] when is super.foo(o)=="bar"?
From:       Jochen Theodorou <blackdrag () gmx ! org>
Date:       2005-10-29 18:41:45
Message-ID: 4363C269.3050804 () gmx ! org
[Download RAW message or body]

John Wilson schrieb:
[...]
> I'm not sure I have explained this correctly. Let me try an example:
> 
> class A {
>     foo(int p) {println "foo(p) in A"}
>     foo(long p, long q) { println "foo(p, q) in A"}
> }
> 
> class B extends A  {
>     foo(int p) {println "foo(p) in B"}
>     foo(int p, int q) { println foo(p, q) in B"}
> }
> 
> 
> B b = new B()
> A a = b
> 
> a.foo(1)         // should print "foo(p) in B"
> a.foo(1, 2)     // should print "foo(p, q) in A"
> 
> b.foo(1)         // should print "foo(p) in B"
> b.foo(1, 2)     // should print "foo(p, q) in B"


if we where in Java this would be correct, yes, but Java has no runtime 
typing like groovy has.
atm we have

a.foo(1,2)== b.foo(1,2)

[...}
> If we do want to deliver the behaviour above then we can't do it  using 
> our existing MetaClass implementation (at least, I can't see  how to do 
> it).

a method would need the additional information if it is overwriting a 
former implementation. For exmaple with using a pointer to the former 
implementation. Then this has to be used instead.

> Do you agree that the above behaviour is the "correct" behaviour and,  
> if so, do you think it matters if we deviate from this behaviour.

If the above is correct, then any deviation would not be correct. And I 
think it may matter if don't give people the ability to somehow choose 
the method that should be called. This is not Self.

[prev in list] [next in list] [prev in thread] [next in thread]