Walter Bright wrote:
> "xs0" <xs0@xs0.com> wrote in message news:dvpgtm$ua2$1@digitaldaemon.com...
>> Walter Bright wrote:
>>> I wanted to get the interface covariant problem fixed for the library guys.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>> Out of curiosity - how did you implement it?
> 
> The type returned by a virtual function is the type of its introducing function. After the function returns, it is cast to the derived return type. 

Hmm, so casting between FooInterface[] and FooClass[] still doesn't work, right? Are you sure that's better than spending a few cycles per method call? Furthermore, some common operations would actually be faster:

- returning interfaces from functions :)
- calling methods defined in Object
- testing for equality

BTW, the spec should say something on that matter, I think you should either make the array casting work or declare it illegal, as an invalid reference is utterly useless. At least one will get a nice error message instead of a big "WTF?!?" expression on his face, when he tries to call a method :)


xs0

"xs0" <xs0@xs0.com> wrote in message news:dvq249$1ljb$1@digitaldaemon.com...
> Hmm, so casting between FooInterface[] and FooClass[] still doesn't work, right?

That's right.

> Are you sure that's better than spending a few cycles per method call? Furthermore, some common operations would actually be faster:
>
> - returning interfaces from functions :)
> - calling methods defined in Object
> - testing for equality
>
> BTW, the spec should say something on that matter, I think you should either make the array casting work or declare it illegal, as an invalid reference is utterly useless. At least one will get a nice error message instead of a big "WTF?!?" expression on his face, when he tries to call a method :)
>
>
> xs0

Walter Bright wrote:
> "xs0" <xs0@xs0.com> wrote in message news:dvq249$1ljb$1@digitaldaemon.com...
>> Hmm, so casting between FooInterface[] and FooClass[] still doesn't work, right?
> 
> That's right.
> 
>> Are you sure that's better than spending a few cycles per method call? Furthermore, some common operations would actually be faster:
>>
>> - returning interfaces from functions :)
>> - calling methods defined in Object
>> - testing for equality
>>
>> BTW, the spec should say something on that matter, I think you should either make the array casting work or declare it illegal, as an invalid reference is utterly useless. At least one will get a nice error message instead of a big "WTF?!?" expression on his face, when he tries to call a method :)
>>
>>
>> xs0 
> 
> 

And the rest of the post...?

xs0 wrote:
> Walter Bright wrote:
>> I wanted to get the interface covariant problem fixed for the library guys.
>>
>> http://www.digitalmars.com/d/changelog.html
> 
> Out of curiosity - how did you implement it?

The same way in which covariantly overriding a class method is implemented, surely.  Strikes me as trivial ... unless "the" interface covariant problem is something different from the two interface covariant problems I've seen....

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> xs0 wrote:
>> Walter Bright wrote:
>>> I wanted to get the interface covariant problem fixed for the library guys.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>
>> Out of curiosity - how did you implement it?
> 
> The same way in which covariantly overriding a class method is implemented, surely.  Strikes me as trivial ... unless "the" interface covariant problem is something different from the two interface covariant problems I've seen....

Well, there's quite a difference between classes and interfaces in handling covariance:

- all class references to the same object have the same value (i.e. they point to the same address), regardless of their type
- interface references to the same object, on the other hand, don't point to the same address

So, for class covariance to work, nothing needs to be done, except of course checking at compile time whether the two types are indeed covariant. With interfaces, some juggling needs to be done to produce the correct reference.

Of course, all that interface ref juggling produces problems, and I've been trying to convince Walter to change the way interfaces are implemented, but no success so far :)


xs0

"Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dvr1n7$2sub$1@digitaldaemon.com...
> And the rest of the post...?

Casting is a blunt instrument, you need to be careful with it. Disabling casting is a bad idea, because one needs a way around the type system.

xs0 wrote:
> Stewart Gordon wrote:
>> xs0 wrote:
>>> Walter Bright wrote:
>>>> I wanted to get the interface covariant problem fixed for the library guys.
>>>>
>>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> Out of curiosity - how did you implement it?
>>
>> The same way in which covariantly overriding a class method is implemented, surely.  Strikes me as trivial ... unless "the" interface covariant problem is something different from the two interface covariant problems I've seen....
> 
> Well, there's quite a difference between classes and interfaces in handling covariance:
> 
> - all class references to the same object have the same value (i.e. they point to the same address), regardless of their type
> - interface references to the same object, on the other hand, don't point to the same address
<snip>

I think we are talking at cross purposes.

The two interface covariance problems I know of are:

(a) a method defined in an interface cannot be implemented with a covariant return type - this is a trivial matter of compile-time type checking and is now fixed

(b) strange things happen when you try to override a method with an interface return type to have a class return type - this bug is still there

http://d.puremagic.com/bugzilla/show_bug.cgi?id=65

What is this other issue you're talking about, which is also fixed?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Walter Bright wrote:
> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dvr1n7$2sub$1@digitaldaemon.com...
>> And the rest of the post...?
> 
> Casting is a blunt instrument, you need to be careful with it. Disabling casting is a bad idea, because one needs a way around the type system. 

So how come you can't cast a double to int delegate(int)? :P

You can still go via void*, if you want to. But normally, it should be forbidden, because the result is both useless and dangerous (in the sense that attempting to use it will call some random method). I can't believe you don't agree this should be an error; currently it's not even a run-time error!?!

Note that this will be a major minus for anyone coming from Java. There, it's completely natural that a FooClass[] can be treated as FooInterface[] and Anything[] can be treated as Object[] (the cast is even implicit).

Furthermore, it's quite common to refactor code by making type Whatever an interface when it was a class before, and while you claim you want D to be practical, you obviously expect a coder to manually go through the entire code base each time he does that, just in case the type was used in a way that won't work anymore.


xs0

Stewart Gordon wrote:
> xs0 wrote:
>> Stewart Gordon wrote:
>>> xs0 wrote:
>>>> Walter Bright wrote:
>>>>> I wanted to get the interface covariant problem fixed for the library guys.
>>>>>
>>>> Out of curiosity - how did you implement it?
>>>
>>> The same way in which covariantly overriding a class method is implemented, surely.  Strikes me as trivial 
>>
>> Well, there's quite a difference between classes and interfaces in handling covariance:
>>
>> - all class references to the same object have the same value (i.e. they point to the same address), regardless of their type
>> - interface references to the same object, on the other hand, don't point to the same address
> 
> I think we are talking at cross purposes.

Could be..

> What is this other issue you're talking about, which is also fixed?

I was just trying to say covariance is not done the same way with interfaces as with classes, and is not quite as trivial :)


xs0

xs0 wrote:
> Walter Bright wrote:
>> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dvr1n7$2sub$1@digitaldaemon.com...
>>> And the rest of the post...?
>>
>> Casting is a blunt instrument, you need to be careful with it. Disabling casting is a bad idea, because one needs a way around the type system.
> 
> So how come you can't cast a double to int delegate(int)? :P
> 
> You can still go via void*, if you want to. But normally, it should be forbidden, because the result is both useless and dangerous (in the sense that attempting to use it will call some random method). I can't believe you don't agree this should be an error; currently it's not even a run-time error!?!
> 
> Note that this will be a major minus for anyone coming from Java. There, it's completely natural that a FooClass[] can be treated as FooInterface[] and Anything[] can be treated as Object[] (the cast is even implicit).
> 
Yes, if this is not "fixed", we certainly need some Java->D tutorials regarding this issue. IMHO all ugly explicit casts should be done behind the scenes.

> Furthermore, it's quite common to refactor code by making type Whatever an interface when it was a class before,

Exactly.

> and while you claim you want D
> to be practical, you obviously expect a coder to manually go through the
> entire code base each time he does that, just in case the type was used
> in a way that won't work anymore.

No! It shouldn't go that way. Usually these casts aren't necessary in CPU-intensive loops (at least they can be avoided). An extra overhead from implicit reference handling wouldn't cause much performance loss.