www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.150 release

reply "Walter Bright" <newshound digitalmars.com> writes:
I wanted to get the interface covariant problem fixed for the library guys.

http://www.digitalmars.com/d/changelog.html
Mar 19 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dvj3fi$2jb0$1 digitaldaemon.com...

I wanted to get the interface covariant problem fixed for the library guys.

 http://www.digitalmars.com/d/changelog.html


So.. what's changed?  ;)  (the changelog isn't updated)

Man, I thought I was the only one up this late.
Mar 19 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dvj3lk$2jg4$1 digitaldaemon.com...

 So.. what's changed?  ;)  (the changelog isn't updated)


Scratch that, it just did.
Mar 19 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dvj3fi$2jb0$1 digitaldaemon.com...

I wanted to get the interface covariant problem fixed for the library guys.


Sorry for posting so many times, but thank you so much for covariant 
interface returns.
Mar 19 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dvj435$2k5p$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:dvj3fi$2jb0$1 digitaldaemon.com...

I wanted to get the interface covariant problem fixed for the library 
guys.


 Sorry for posting so many times, but thank you so much for covariant 
 interface returns.


You're most welcome.
Mar 19 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sun, 19 Mar 2006 03:37:07 -0500, Walter Bright  
<newshound digitalmars.com> wrote:


 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
 news:dvj435$2k5p$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:dvj3fi$2jb0$1 digitaldaemon.com...

 I wanted to get the interface covariant problem fixed for the library
 guys.


 Sorry for posting so many times, but thank you so much for covariant
 interface returns.


 You're most welcome.


It sounded like you needed to use a trick to get this to work; is there a  
runtime penalty?
Mar 19 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.s6n41na6po9bzi moe...

 It sounded like you needed to use a trick to get this to work; is there a 
 runtime penalty?


Yes, it's 3 or 4 instructions.
Mar 19 2006
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
Walter Bright wrote:


 I wanted to get the interface covariant problem fixed for the library
 guys.
 
 http://www.digitalmars.com/d/changelog.html



Walter, you're my hero!  I'll have a look-see tomorrow, but I'm excited.

~John Demme
Mar 19 2006
parent reply John Demme <me teqdruid.com> writes:
I ran some tests earlier today, and I love it!  This is great!

Thanks, Walter

~John Demme

John Demme wrote:


 Walter Bright wrote:
 

 I wanted to get the interface covariant problem fixed for the library
 guys.
 
 http://www.digitalmars.com/d/changelog.html


 
 
 Walter, you're my hero!  I'll have a look-see tomorrow, but I'm excited.
 
 ~John Demme
Mar 19 2006
next sibling parent John Reimer <terminal.node gmail.com> writes:
John Demme wrote:

 I ran some tests earlier today, and I love it!  This is great!
 
 Thanks, Walter
 
 ~John Demme
 


Excellent!  I'm really glad this was fixed!

-JJR
Mar 19 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:dvld5s$1e7c$1 digitaldaemon.com...

I ran some tests earlier today, and I love it!  This is great!

 Thanks, Walter


You're welcome! I'm glad it's working. I thought it would be much harder to 
implement than it turned out to be.
Mar 19 2006
parent reply Ant <duitoolkit yahoo.ca> writes:
Walter Bright wrote:

 "John Demme" <me teqdruid.com> wrote in message 
 news:dvld5s$1e7c$1 digitaldaemon.com...

 I ran some tests earlier today, and I love it!  This is great!

 Thanks, Walter


 
 You're welcome! I'm glad it's working. I thought it would be much harder to 
 implement than it turned out to be. 
 
 


That's the mark of a good design ;)

Ant
Mar 19 2006
parent Dave <Dave_member pathlink.com> writes:
In article <dvlhg4$1koq$1 digitaldaemon.com>, Ant says...

Walter Bright wrote:

 "John Demme" <me teqdruid.com> wrote in message 
 news:dvld5s$1e7c$1 digitaldaemon.com...

 I ran some tests earlier today, and I love it!  This is great!

 Thanks, Walter


 
 You're welcome! I'm glad it's working. I thought it would be much harder to 
 implement than it turned out to be. 
 
 


That's the mark of a good design ;)

Ant


I agree - I recall seeing Walter making similiar remarks about implementing
other features of D. Pretty cool.
Mar 20 2006
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:

 I wanted to get the interface covariant problem fixed for the library guys.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Thank you. :)
Mar 19 2006
prev sibling next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
Nice work!

(there's a small typo in the changelog: converstion)

L.
Mar 19 2006
prev sibling next sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <dvj3fi$2jb0$1 digitaldaemon.com>, Walter Bright says...

I wanted to get the interface covariant problem fixed for the library guys.

http://www.digitalmars.com/d/changelog.html


Pardon my ignorance, but what is (was) "the interface covariant problem"?

Nick
Mar 20 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message 
news:dvmuuu$kjm$1 digitaldaemon.com...

 In article <dvj3fi$2jb0$1 digitaldaemon.com>, Walter Bright says...

I wanted to get the interface covariant problem fixed for the library 
guys.


 Pardon my ignorance, but what is (was) "the interface covariant problem"?


See the "interfaces :-(" thread over in digitalmars.D.dtl
Mar 20 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 I wanted to get the interface covariant problem fixed for the library guys.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


:)
Mar 21 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
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?


xs0
Mar 21 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Mar 21 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Mar 21 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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
Mar 21 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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...?
Mar 22 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Mar 22 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Mar 22 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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.
Mar 22 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Mar 22 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Mar 22 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Mar 22 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Mar 22 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
xs0 wrote:

 Stewart Gordon wrote:


<snip>

 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 :)


Yes, but UIMS it _is_ trivial for the bug that I've discovered is fixed.

If you take this case (issue (a) in my last post)

----------
class Qwert {}

interface Yuiop {
     Qwert asdfg();
}

class Hjkl : Yuiop {
     Hjkl asdfg() { return new Hjkl; }
}
----------

then since Qwert and Hjkl are both classes, and as you say


 - all class references to the same object have the same value 
 (i.e. they point to the same address), regardless of their type






no runtime conversion is needed.  The problem was purely that, when the 
compiler checked whether an interface is fully implemented, it would 
check for an exact match instead of a covariant match.

OTOH Walter also said in another branch:

"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."

This doesn't matter to issue (a), but it's what I had thought up before 
as a way of dealing with issue (b).  However, issue (b) isn't fixed, so 
I'm wondering what it's about.  Is there a subset of cases of issue (b) 
that is fixed now?  I'd like to see an example.

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.
Mar 23 2006