Re: extends and implements
Jesse Phillips Wrote: The second is when I want to find its definition. Hmmm, should I be greping for /class Window/, /interface Window/, or /struct Window/ [a-z]* Window ?
Re: extends and implements
On Mon, 07 Nov 2011 13:22:07 -0500, %u n...@devnull.com wrote: Hello. I know D isn't Java, but one trivial thing I liked about Java is the introduction of 'extends' and 'implements' as keywords as ways to clarify the class relationships when defining a class. You know: class Subclass extends SuperClass implements AnInterface { ... } Will they ever add this in to D? No. If not, why not? In order for such a humongously code-breaking change to occur, there would have to be dire reasons why this was necessary. Because you liked Java is not a qualifying reason. -Steve
Re: extends and implements
If you need some kind of textual information on whether its a class or an interface, you can name your interfaces with an I. interface IShape { } abstract class Drawable { } class Rectangle : IShape, Drawable {} It's pretty common in other languages, I've seen it used in D as well.
Re: extends and implements
On 07-11-2011 19:22, %u wrote: Hello. I know D isn't Java, but one trivial thing I liked about Java is the introduction of 'extends' and 'implements' as keywords as ways to clarify the class relationships when defining a class. You know: class Subclass extends SuperClass implements AnInterface { ... } Will they ever add this in to D? If not, why not? thanks. Programming isn't natural language (or some variation thereof). I don't see what's wrong with using ':' for this. It's clear what it does, and not ambiguous in any way. - Alex
Re: extends and implements
You can do this and/or use the convention of extends first, implements second: class Rectangle : Drawable, IShape, IOtherInterface {} If you're really concerned about clarity, use comments: class Rectangle : /* extends */ Drawable, /* implements */ IShape { } Andrej Mitrovic wrote: If you need some kind of textual information on whether its a class or an interface, you can name your interfaces with an I. interface IShape { } abstract class Drawable { } class Rectangle : IShape, Drawable {} It's pretty common in other languages, I've seen it used in D as well.
Re: extends and implements
You can do this and/or use the convention of extends first, implements second: class Rectangle : Drawable, IShape, IOtherInterface {} It's not a convention, the spec demands that. http://d-programming-language.org/class.html If you're really concerned about clarity, use comments: class Rectangle : /* extends */ Drawable, /* implements */ IShape { } Good point.
Re: extends and implements
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Mon, 07 Nov 2011 13:22:07 -0500, %u n...@devnull.com wrote: In order for such a humongously code-breaking change to occur, there would have to be dire reasons why this was necessary. Because you liked Java is not a qualifying reason. -Steve Hey man, Sorry if I annoyed you. No need to feel insulted. I get it: the *real* reason is that it will break alot of code. I'm just asking, it's not a big deal. I find that it helps readability. But as others have stated, you list the the extended class first and that's good enough! thanks.
Re: extends and implements
On Mon, 07 Nov 2011 14:07:56 -0500, %u n...@.com wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Mon, 07 Nov 2011 13:22:07 -0500, %u n...@devnull.com wrote: In order for such a humongously code-breaking change to occur, there would have to be dire reasons why this was necessary. Because you liked Java is not a qualifying reason. -Steve Hey man, Sorry if I annoyed you. No need to feel insulted. I get it: the *real* reason is that it will break alot of code. I'm just asking, it's not a big deal. I find that it helps readability. But as others have stated, you list the the extended class first and that's good enough! The Internet is not always conducive to the emotional interpretation of words. Sorry if I sounded annoyed/insulted. I simply was identifying that you asked for a change that would break almost all code, and your reason was because you liked it. I'm not annoyed, but I wanted you to understand what you were asking for and what appears to be your reason. We would need more -- a lot more. That being said, even if there was a really good reason (maybe there is, I don't know), the bar for changing something so common in the syntax has to be set very very high. It may be something we can't change even if it's for a good reason. -Steve
Re: extends and implements
Andrej Mitrovic wrote: class Rectangle : IShape, Drawable {} It's pretty common in other languages, I've seen it used in D as well. I used the same naming convention for interfaces until I saw this presentation: http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP- in-Java (jump to 0:42 if you do not want to see this brilliant presentation). In short there is an interface RecentlyUsedList, and Kevin recommends that good name for implementation is something like ArrayBasedRecentlyUsedList. And he is also against IRecentlyUsedList names... I actually agree with what he suggests, and stopped using INames for interfaces. :) PS. the presentation is not Java advocacy, it contains lots of Java criticism...
Re: extends and implements
On Mon, 07 Nov 2011 18:22:07 +, %u wrote: Hello. I know D isn't Java, but one trivial thing I liked about Java is the introduction of 'extends' and 'implements' as keywords as ways to clarify the class relationships when defining a class. You know: class Subclass extends SuperClass implements AnInterface { ... } Will they ever add this in to D? If not, why not? thanks. There are only two instances I like know if something is an interface or class. The first is when I am defining it, for some reason I want to tell the whole world, Hey I'm building an interface here so be sure to include these. Which really isn't important. The second is when I want to find its definition. Hmmm, should I be greping for /class Window/, /interface Window/, or /struct Window/ Otherwise the distinction has been pointless.
Re: extends and implements
On 2011-11-07 20:36, Dejan Lekic wrote: Andrej Mitrovic wrote: class Rectangle : IShape, Drawable {} It's pretty common in other languages, I've seen it used in D as well. I used the same naming convention for interfaces until I saw this presentation: http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP- in-Java (jump to 0:42 if you do not want to see this brilliant presentation). In short there is an interface RecentlyUsedList, and Kevin recommends that good name for implementation is something like ArrayBasedRecentlyUsedList. And he is also against IRecentlyUsedList names... I actually agree with what he suggests, and stopped using INames for interfaces. :) PS. the presentation is not Java advocacy, it contains lots of Java criticism... If the interfaces are the primary API, not implementation specific classes, then the interfaces should not be have a ugly ma,e qualify them with I or similar. If there is a need to separate the class and interface names then choose the ugly name of the implementation classes. -- /Jacob Carlborg
Re: extends and implements
On 2011-11-08 03:07, Jesse Phillips wrote: On Mon, 07 Nov 2011 18:22:07 +, %u wrote: Hello. I know D isn't Java, but one trivial thing I liked about Java is the introduction of 'extends' and 'implements' as keywords as ways to clarify the class relationships when defining a class. You know: class Subclass extends SuperClass implements AnInterface { ... } Will they ever add this in to D? If not, why not? thanks. There are only two instances I like know if something is an interface or class. The first is when I am defining it, for some reason I want to tell the whole world, Hey I'm building an interface here so be sure to include these. Which really isn't important. The second is when I want to find its definition. Hmmm, should I be greping for /class Window/, /interface Window/, or /struct Window/ Otherwise the distinction has been pointless. This should be handled by an IDE/editor with go-to-definition. -- /Jacob Carlborg