• Marc <Marc_member pathlink.com> May 18 2004
• J Anderson <REMOVEanderson badmama.com.au> May 18 2004
• marc.noirotREM OVEfleximage.fr May 18 2004
• J Anderson <REMOVEanderson badmama.com.au> May 18 2004
• marc.noirot REMOVEfleximage.fr May 18 2004
• J Anderson <REMOVEanderson badmama.com.au> May 18 2004
• Marc <marc.noirotMOVE REfleximage.fr> May 18 2004
• J Anderson <REMOVEanderson badmama.com.au> May 18 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jun 04 2004
• Marc <marc.noirotNO flexSPAMimage.fr> Jun 08 2004
• Andy Friesen <andy ikagames.com> May 18 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jun 04 2004
• Genki Takiuchi <takiuchi ntechnology.co.jp> May 18 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jun 04 2004

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

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

  


the worlds most popular language to learn D.

-- 
-Anderson: http://badmama.com.au/~anderson/

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

  


the worlds most popular language to learn D.

-- 
-Anderson: http://badmama.com.au/~anderson/

marc.noirotREM OVEfleximage.fr wrote:

 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 ?
  


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?

-- 
-Anderson: http://badmama.com.au/~anderson/

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 ?

If we make abstraction of the fact that D wants to stick with C++ syntax, what
is the best for someone trying to learn a language from scratch ?
A perlish symbol like ':' expressing 2 notions ? Or two words like 'extends' and
'implements' that leave no doubt about the context ?

Thanks for your patience in answering my irritating questions :P
Marc

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 ?
  


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.

If we make abstraction of the fact that D wants to stick with C++ syntax, what
is the best for someone trying to learn a language from scratch ?
A perlish symbol like ':' expressing 2 notions ? Or two words like 'extends' and
'implements' that leave no doubt about the context ?

Thanks for your patience in answering my irritating questions :P
Marc
  


No worries.


-- 
-Anderson: http://badmama.com.au/~anderson/

ok, what about this ? :

//interclace.d
import std.c.stdio;

//*
version=1;
//*/

version (1) {
interface A {
char [] toString();
}
}
else {
class A {
char [] toString() {
return "3";
}
}
}

/* if version = 1, super.toString == Object.toString,
else super.toString == A.toString */
class B: A {
char [] toString() {
return super.toString() ~ "1";
}
}

void main() {
B b = new B;
printf("B: %s\n", cast(char *)b.toString()); // what does it print ?
}

//EOF

the output of b.toString() is not 'really' predictable if version = 1
(Object.toString seems to print "Object", but is it implementation dependant
?)although both versions are valid and compile fine.
weirdness, weirdnesss, doesn't it look like a potential source of bugs that
could be avoided with explicit "implements" or "extends" ?

Marc wrote:

ok, what about this ? :

//interclace.d
import std.c.stdio;

//*
version=1;
//*/

version (1) {
interface A {
char [] toString();
}
}
else {
class A {
char [] toString() {
return "3";
}
}
}

/* if version = 1, super.toString == Object.toString,
else super.toString == A.toString */
class B: A {
char [] toString() {
return super.toString() ~ "1";
}
}

void main() {
B b = new B;
printf("B: %s\n", cast(char *)b.toString()); // what does it print ?
}

//EOF

the output of b.toString() is not 'really' predictable if version = 1
(Object.toString seems to print "Object", but is it implementation dependant
?)although both versions are valid and compile fine.
weirdness, weirdnesss, doesn't it look like a potential source of bugs that
could be avoided with explicit "implements" or "extends" ?


  


cycle it may be decided that interface A is better off as an abstract 
class (or whatever).  If you had implements and extends you'd need too 
go to every one of your clients code and modify it to work. 

Besides you can easily produce the error message you want by adding a 
stub constructor and calling super.

-- 
-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 ?


 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.

 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

marc.noirotREM OVEfleximage.fr wrote:
 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 ?


It is not a flaw at all, merely a different syntax, as it does not 
effect *what* can be expressed in D, merely how it is expressed.

  -- andy

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


 is familiar to C++ developers ;)
 I think the ':' inheritance syntax is one of C++ flaws. I'm a C++ supporter,


 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






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






?

bye,
Marc


the worlds most popular language to learn D.

-- 
-Anderson: http://badmama.com.au/~anderson/

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
 
 


How about writing like this?

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

"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




 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




 ?

 bye,
 Marc


 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.