I think there's mileage in this idea, but I suspect it's too late to get anything done about. One might also say it's not really important enough to warrant the changes at this point.

<marc.noirotREM@OVEfleximage.fr> wrote in message news:c8coe5$6pj$1@digitaldaemon.com...
> IMHO, the reason you're giving me is not satisfying.
> D is supposed to be a language that solves the flaws of C++.
> That was successfully done with templates, and you won't say that the new
syntax
> is familiar to C++ developers ;)
> I think the ':' inheritance syntax is one of C++ flaws. I'm a C++ supporter,
but
> I find that the words 'extends' and 'implements' are really expressive and
> meaningful (and leave no place for contextual interpretation).
> So, if i follow your argument, why not having D support both syntaxes, so C++
> and Java developers will both feel at ease with it ?
>
> In article <c8clja$2dn$1@digitaldaemon.com>, J Anderson says...
> >
> >Marc wrote:
> >
> >>Hello,
> >>
> >>I'm wondering why D doesn't use the Java-style syntax for class inheritance
> >>(extends, implements), because I thought D's purpose was to have the clearest
> >>possible syntax.
> >>In its current state, it seems to me it's not possible to determine visually
the
> >>type of inheritance, eg.:
> >>
> >>class Y: A, B, C, D
> >>{
> >>}
> >>
> >>is it immediatly possible to say which of A, B, C or D are interfaces or
classes
> >>?
> >>
> >>bye,
> >>Marc
> >>
> >>
> >>
> >D copies a lot of syntax from C++ which makes it easy for people who use the worlds most popular language to learn D.
> >
> >-- 
> >-Anderson: http://badmama.com.au/~anderson/
>
>

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c8d6go$vpm$1@digitaldaemon.com...
> marc.noirot@REMOVEfleximage.fr wrote:
>
> >>Obviously you can't have to many alias for things in languages, it makes the language to broad (language design 1.0 -> unit).  You have to pick one direction and stick with it.  Why not also make blocks { } begin and end?
> >>
> >>
> >>
> >
> >Of course, i agree with you, i was actually being half-sarcastic.
> >
> >But well, let's elude that point...
> >
> >I think ':' is acceptable in C++ because it doesn't have the builtin notion of
> >interface.
> >But like in Java, D's class inheritance and interface implementation are two
> >different notions, so why writing them as if they were the same thing ?
> >
> >
> Often you only want to implement one interface/class and users don't care if its a class or interface.  I believe it helps to keep things like this generic.  You don't need to search the docs to find out if something is an interface or class.  If you need to use more then one interface, then you can search the docs, if nessary.  Furthermore if the developer wishes to change an interface to a class (or visa versa), they won't have maintance problems in D.
>
> If you really want this documentation you can put a comment in.
>

Excellent point. And I should have thought about this before answering the other post in this thread.

DTL relies on some types deriving from template parameters. It would be a restriction if they were required to stipulate whether this parameterising parent was either class or interface.

So I say No! to the idea.

"Genki Takiuchi" <takiuchi@ntechnology.co.jp> wrote in message news:c8ebp7$2uh8$1@digitaldaemon.com...
> Marc wrote:
> > Hello,
> >
> > I'm wondering why D doesn't use the Java-style syntax for class inheritance
> > (extends, implements), because I thought D's purpose was to have the clearest
> > possible syntax.
> > In its current state, it seems to me it's not possible to determine visually
the
> > type of inheritance, eg.:
> >
> > class Y: A, B, C, D
> > {
> > }
> >
> > is it immediatly possible to say which of A, B, C or D are interfaces or
classes
> > ?
> >
> > bye,
> > Marc
> >
> >
> Hi.
> How about writing like this?
>
> class Foo : SuperClass
> ,   InterfaceOne
> ,   InterfaceTwo
> ,   InterfaceThree
> {
> }

I always write inheritance relationships as

class Foo
    : SuperClass
    , InterfaceOne
    , InterfaceTwo
    , InterfaceThree
{
  ...
}

However, I think you may have something with your proposal. We should adopt the convention that the parent class always comes first, and if that's on the same line, then anything below that is an interface.

However, this fails when we want the parent(s) to be dependent on template parameters. Nonetheless, for concrete types, it'd be nice to try and at least follow the principal that parent classes come first.

> Furthermore if the
> developer wishes to change an interface to a class (or visa versa), they
> won't have maintance problems in D.
>

that's not always true...

if an interface becomes a class, then a class extending some superclass AND implementing that former interface will need to be redesigned, because of multiple inheritence not being supported.

if a class becomes an interface, there are big chances that not all methods are implemented by a class using it, so the developer will have to provide default implementations for methods he doesn't care about.

In a pure OOP approach, I can't admit that interfaces and classes are considered the same.

Here are some URLs where the topic is discussed :

http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconAbstractClassesVersusInterfaces.asp
http://c2.com/cgi/wiki?DontDistinguishBetweenClassesAndInterfaces
http://c2.com/cgi/wiki?InterfacesVsClasses

regards,
Marc