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.


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


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

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

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.


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:

 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