As I understand this will work
class A
{
	public int foo () {return 0;}
}

class B: A
	public int foo(){ return 1;}
}


A a = new B();
a.foo -> yields 1

But that won't work
class A {
    public int foo () { return 0; }
}

class B: A{
    public int foo () { return 1; }
    public int bar() { return 0;}
}

int main (){
    A a = new B();
    printf("a.foo() = %d\n", a.foo());
    printf("a.bar() = %d\n", a.bar());
    return 0;
}

So D allows sort of covariant assignment, but for accessing a functoin defined in a descendant the function to be accessed must be part
of the ancestor too. In the second example bar must be defined in A too.

Is that correct?

Regards
Friedrich

"Friedrich Dominicus" <frido@q-software-solutions.com> wrote in message news:bhakdt$o1s$1@digitaldaemon.com...
> As I understand this will work
> class A
> {
> public int foo () {return 0;}
> }
>
> class B: A
> public int foo(){ return 1;}
> }
>
>
> A a = new B();
> a.foo -> yields 1
>
> But that won't work
> class A {
>      public int foo () { return 0; }
> }
>
> class B: A{
>      public int foo () { return 1; }
>      public int bar() { return 0;}
> }
>
> int main (){
>      A a = new B();
>      printf("a.foo() = %d\n", a.foo());
>      printf("a.bar() = %d\n", a.bar());
>      return 0;
> }
>
> So D allows sort of covariant assignment, but for accessing a functoin
> defined in a descendant the function to be accessed must be part
> of the ancestor too. In the second example bar must be defined in A too.
>
yes, D is statically typed (like Java, C++ Delphi etc) unlike Lua, self
.....

so A a;

although a can hold a reference to B or any other sub class of A you have to
cast a to the subclass before using those "messages" or "methods"
i.e.
>      printf("a.bar() = %d\n", (cast(B)a).bar());
cast(B)a  will return null if a is not castable to B

class C { .. }
you could not do cast(C)a as there is not way that `a` can be a subclass of
C (single inheritance only)
the types and inheritance tree for types are all determinded at compile time
late binding is performed via a virtual function table (vtbl) so a.foo()
will be converted to evoke a->vtbl[index of method foo]( a, params to foo );
the compiler has to be able to determine the vtbl index at compile time (not
runtime)

you may have
class D : A {
    void ping() { }
    int bar() { return 44; }
}

a could be a B or D; the vtable entry for bar might be 2 (B) 3 (D) etc ...

Friedrich Dominicus wrote:

> So D allows sort of covariant assignment, but for accessing a functoin defined in a descendant the function to be accessed must be part
> of the ancestor too. In the second example bar must be defined in A too.
> 
> Is that correct?

These things must be obvious to you! BTW, how's your own "Q" language doing?

In your example "a" is of type "A", which doesn't have a "bar()" defined.

If you think you know that a is actually of type B, you can go ahead and do so:

int main (){
    A a = new B();
    printf("a.foo() = %d\n", a.foo());
    printf("a.bar() = %d\n", cast(B) (a.bar()) );
    return 0;
}

cast will reward you with an exception, if you were wrong.

Can you do such acrobacy in Eiffel or Q as you have tried to suggest with your example?

-i.

Ilya Minkov says...
>
>BTW, how's your own "Q" language doing?
>

That's one more for the obscure languages list.  The only Q that I had known
about lived here.
http://www.musikwissenschaft.uni-mainz.de/~ag/q/q.php

Friedrich Dominicus' Q language lives here http://www.q-software-solutions.com/about.shtml

(Almost all single-letter language names are taken, for those contemplating a
new one.)

Mark

Ilya Minkov wrote:
> Friedrich Dominicus wrote:
> 
>> So D allows sort of covariant assignment, but for accessing a functoin defined in a descendant the function to be accessed must be part
>> of the ancestor too. In the second example bar must be defined in A too.
>>
>> Is that correct?
> 
> 
> These things must be obvious to you! BTW, how's your own "Q" language doing?

Well I had a wrong example on my mind. I rewrote the stuff and found the
that D is correct and I was wrong.


> 
> Can you do such acrobacy in Eiffel or Q as you have tried to suggest with your example?
Maybe with an revrese assignment... Quite interesting that at least some
remember me talking about Q years ago. Q kinda works, not all too much I admit....

Regards
Friedrich

"Friedrich Dominicus" <frido@q-software-solutions.com> escreveu na mensagem news:bhfhdv$2ikm$1@digitaldaemon.com...
> Ilya Minkov wrote:
> > BTW, how's your own "Q" language doing?
>
> Well I had a wrong example on my mind. I rewrote the stuff and found the that D is correct and I was wrong.
>
> > Can you do such acrobacy in Eiffel or Q as you have tried to suggest with your example?
> Maybe with an revrese assignment... Quite interesting that at least some remember me talking about Q years ago. Q kinda works, not all too much I admit....
>
> Regards
> Friedrich

Hi,

    I'm also interested in Q, it had some nice ideas in it. Perhaps you
could start a open-source project on Q, compiling it to D ;).

    Best regards,
    Daniel Yokomiso.

"Sincerity is the key. If you can fake that, you've got it made."
 - George Burns



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 14/8/2003