Regan Heath wrote:
> 
> Aren't you only 'overloading/overriding' if the function signature is identical?
> Otherwise you're providing a specialisation i.e.

I find it hard to follow your argumentation, probably due to the above statement.

overloading and overriding is two different things:

overriding is the reimplementation of a method in a subclass (having the same signature as a method in the superclass)

overloading is when several methods/functions with the same name, but different signatures are provided.

Lars Ivar Igesund

Farmer wrote:

> Why should D take the look-up rules of a legacy language called Java?
> Isn't it better to stick with the way modern languages like C++ and C# do it? 

Heh, funny.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsbrvovk35a2sq9@digitalmars.com...
> On Mon, 26 Jul 2004 22:15:32 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:

> Using your example:
> class A { void foo( char x ) {} }
> class B : A {}
> class C : B {}
> class D : C {}
> class E : D {}
> class F : E, I { implement void foo( int x ) {} }
>
> Would error saying "F.foo(int) does not implement any interface (I)"
> If the user then changed it to the correct definition:
>    class F : E, I { implement void foo( char x ) {} }
>
> assuming override is mandatory, it would again error "F.foo(char)
> overrides A.foo(char)"
> so the user now needs:
>    class F : E, I { implement override void foo( char x ) {} }
>
> This is _another_ argument _for_ a mandatory override keyword, _even if_ you don't agree a new implement keyword is a good idea.

I think it's good example! Thanks Regan. I'm almost lost in this debates about override rules but I personally feel java rules are more intuitive for me (java experience). I've just now (reading debates) realized the actual mean of 'alias' and what does it for! And I think using alias in the inheritance is very NON-intuitive IMO but may be it's a habbit?

What I do like in java are explicit keywords - 'extends' + 'implements'. What's all at this time.

--------
Sorry for Off-topic:
I'm not lawyer and don't know the rules. Actually they are can be different
in different countries.

It seems to me like this:
For example, I'm single heir and I inherited some property from my parents
by 'testament', 'will'. Testament says - I can use them all (inherited).

1. I have inherited all property 'by default' and can use it as I wish. 2. I can use them all because the are inherited by me.

3. But if I would like to give, bequeath it to my child I must write about usage of inheritance (EVERY property) 'explicitly' but NOT by default? Sound a little strang for me but it depends...

Sorry again, just thoughts.

----
Yuriy.

In article <Xns95337DF59537itsFarmer@63.105.9.61>, Farmer says...

>Why should D take the look-up rules of a legacy language called Java?
>Isn't it better to stick with the way modern languages like C++ and C# do it?

Not wishing to be /too/ pedantic, but C++ came before Java. So by that reckoning, C++ is "legacy" and Java is "modern".

Jill

Sean Kelly wrote:

> In article <ce4h8p$1nq7$1@digitaldaemon.com>, Kris says...
> 
>>Minor detail: You'll forgive me for not wishing to confuse the Interface
>>Resolution issue with that of the peek-a-boo game ~ one cannot alias a
>>super-class method to fulfill an interface contract. You are simple forced
>>to stub & dispatch. At any level of complexity, these stubs become a real
>>issue.
> 
> 
> Well that sucks.  I hadn't realized that.  Is the same true with "using" in C++?

Yes, I would think so, but that is because C++ don't have interfaces, only the possibility of classes that are abstract through having only method prototypes. These classes can be inherited to function as interfaces, but then other superclasses would be independent of the interface in the inheritance hierarchy.

Lars Ivar Igesund

In article <ce4st1$1sc2$1@digitaldaemon.com>, Lars Ivar Igesund says...

>overriding is the reimplementation of a method in a subclass (having the same signature as a method in the superclass)
>
>overloading is when several methods/functions with the same name, but different signatures are provided.

So you can have a function which both overloads and overrides at the same time. And then there's "operator overloading" which means something else entirely, so now you can both overload and override an operator overload. Ah Jeez, I'm giving up on this one. Personally I think that "superclass" and "subclass" are named upside down*, so who am I to argue?

Jill  :)


*If A is a superclass of B, then the set of member variables/methods of A is a SUBset of the set of member variables/methods of B.

In article <ce4vka$1tvt$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>Sean Kelly wrote:
>
>> In article <ce4h8p$1nq7$1@digitaldaemon.com>, Kris says...
>> 
>>>Minor detail: You'll forgive me for not wishing to confuse the Interface Resolution issue with that of the peek-a-boo game ~ one cannot alias a super-class method to fulfill an interface contract. You are simple forced to stub & dispatch. At any level of complexity, these stubs become a real issue.
>> 
>> Well that sucks.  I hadn't realized that.  Is the same true with "using" in C++?
>
>Yes, I would think so, but that is because C++ don't have interfaces, only the possibility of classes that are abstract through having only method prototypes.

Oops, of course.  No wonder I had never run into it before.


Sean

On Mon, 26 Jul 2004 23:02:07 -0700, Walter <newshound@digitalmars.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsbr73ixa5a2sq9@digitalmars.com...
>> On Mon, 26 Jul 2004 19:50:11 -0700, Walter <newshound@digitalmars.com>
>> wrote:
>>
>> >
>> > "Regan Heath" <regan@netwin.co.nz> wrote in message
>> > news:opsbrrs9pv5a2sq9@digitalmars.com...
>> >> Aren't you only 'overloading/overriding' if the function signature is
>> >> identical?
>> >
>> > No. The rule is the names are looked up first, *then* overload
> resolution
>> > happens.
>>
>> I know what the rule is, all I'm saying is that you're not technically
>> overloading unless the function signature is the same,
>
> I think you mean "overriding" <g>.

Either or, I used both above, you used both above in your original paragraph.

>> you're supplying a specialisation.
>
> Specialization is the wrong word to use here, specialization really applies
> to templates, not functions.

Common usage agrees with you, and perhaps my usage is a little loose, what I meant was that if you have a method foo(int) and you create foo(float) you're creating a method specifically to handle floats, thus it's a specialist method.. the looseness comes from the fact that the original method was also a specialist method to handle int, in fact that there is no generic method as it's impossible to write one, as we have no variant type.

> I admit the various jargons can be confusing -
> I think we understand each other, we're just not understanding each other's
> jargon.

Perhaps.. what I am trying to say is that this:

class X1 {
  void foo(int);
}

class X2 : X1 {
  void foo(float);
}

is _not_ the same as:

class X1 {
  void foo(int);
}

class X2 : X1 {
  void foo(int);
}

the former 'extends' the parent class (I'll use extends instead of specialise), the latter overrides a method in the parent class.

Ideally they should be treated differently. The former should be treated the same as if the methods had different names.

This brings me to Issue 1:

Requiring the use of 'override' facilitates treating them differently, if the programmer intends to override they say so, otherwise they assumed to be extending. This catches the accidental override and accidental not-override bugs.

I believe it's a safe simple addition to the language.


Issue 2:

When you are extending a class you want it's public methods to be part of the child class, this works fine so long as the methods have different names, but, as soon as the methods have the same name you have to do something extra, i.e. use an alias, this is counter intuitive. I have no solution to this issue.


Issue 3:

When using interfaces, inherited methods do not satisfy the interface, this to me, is lunacy... why shouldn't they? The class does provide the methods the interface requires, it seems to me that to solve this all you need to do is walk the class heirarchy and notice the methods. Such that the following should be valid:

interface FooBar {
  void foo(int a);
  void bar(int a);
}

class Parent {
  void foo(int a)
  {
    printf("Parent:foo:int\n");
  }
}

class Child : Parent, FooBar {
  void bar(int a)
  {
    printf("Child:bar:int\n");
  }
}

void main()
{
  Child c = new Child();
  c.foo(1);
  c.bar(2);
}


If Issue 2 and Issue 3 collide then it should be possible to use alias to alias-in the methods to satisfy the interface.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Tue, 27 Jul 2004 08:36:45 +0100, Lars Ivar Igesund <larsivar@igesund.net> wrote:

> Regan Heath wrote:
>>
>> Aren't you only 'overloading/overriding' if the function signature is identical?
>> Otherwise you're providing a specialisation i.e.
>
> I find it hard to follow your argumentation, probably due to the above statement.
>
> overloading and overriding is two different things:
>
> overriding is the reimplementation of a method in a subclass (having the same signature as a method in the superclass)
>
> overloading is when several methods/functions with the same name, but different signatures are provided.

I mean't overriding. I now have a better understanding of the common terminology, consider my paragraph to be...

"
Aren't you only overriding if the function signature is identical?
Otherwise you're providing an overloading i.e.
"

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Kris, I see I can follow your thoughts, and you can follow mine:

We both agree that the overloading-rules are non-intuitive (I never admitted this before, but I do agree). We both agree that the 'alias hack' solves your problems, but it's non-intuitive, inconvenient, and against accepted OO-principles.

We both agree, that the way, D currently supports interfaces, you *can* gain the basic (important) benefits of interfaces. although, it's non-intuitive, inconvenient, and limiting.

What's different are not our *thoughts* (they are pretty much in line),
but our conclusions. <em> You repeately argued that things are bullshit,
since they are not intuitive. </em>
Here my fundamental opinion is apparently different from yours. When I think
of programming matters (language, libraries, methods), it is irrelevant
whether sth. is intuitive or not. It is far more important, that things are
consistent and logical.
I prefer simple rules, that can be learnt and understood rather than
intuitive rules or rules that are tweaked to archive intuitive results. I
think that intuitive things are easy grasp, at first, but in the long run
they are impossible to master.  But the worst thing about intuitive designs
are that they are context sensitive. What's intuitive depends on your
background, on what you are currently working, and on personal preference.

Since I have so strong feelings about the uselessness of intuitive design [Not long, when I read about Ruby that its designer made the language as intuitive as he could do. My intuition said 'Bullshit, don't bother to look at this.'], I fail to understand your paper, which appeals more to the reader's intuition than providing well presented trains of thoughts.


I don't think its much of relevance, but my inituition share's you concerns
that D's rules for implementation of interfaces, will/should be improved.
I'm especialy concerned regarding templates (as Andy Friesen pointed out)
and big messy class inheritance tries build by (even bigger an messier)
programming teams. Regarding the 'alias peek a boo' game, I only comment that
in the past, Walter had constantly sticked with 'C++' concepts,  even when
these concepts were undeniably more flawed, than the 'alias peek a boo' game.


Farmer.


>> Disagree. It helped me better understand the D language and restrengthen
> my
>> fading C++ skills. Futhermore some of those cool things you can do with
> C++
>> sprung back to my mind:
> 
> Glad to hear it! My comments are all made in context Farmer: you're simply splitting hairs.

I'm splitting hairs for good reasons: I consider your comment
<quote>
Posting that example of how C++ operates had absolutely zero value: we
already /know/ it works that way ~ [...]
</quote>
as rude and unjustified:
Not everyone has your skills and background to properly evaluate the 'alias-
peek-a-boo game'. Walter is doing good in *repeatedly* explaining and
clarifying the rules of D. (Especially if the description of these rules are
so badly lacking in the specification ;-)



>> Now some comments regarding your document (revision 4):
>>
>> Chapter External Names:
>>
>> Why is that chapter even still listed?
> 
> Apparently, it must be for no reason other than to annoy you, Farmer. Don't you think it has some "educational" value? Just as example above had for you? Wouldn't you rather see the entire document simply disappear instead?

No, D needs critique papers to evolve and get rid of it's flaws.

But why is there? (well, annoying me is for sure a good reason)
Walter has already admitted that the presented problems are due to compiler-
bugs.
Would you also leave functions originally written to work-around some OS
bugs, in code - or would you clean it up, once the issues were solved?


>> And why do present the other solutions first, that are not really
> solutions,
>> since why are *different* from the original example?
> 
> Forgive me; my parser just failed.

I can fix that:
And why do <you> present the other solutions first, that are not really
solutions, since <they> are *different* from the original example?

And to make sure it gets understood in the semantic phase ;-)
Just one comment: Though, I'm used to see deliberate manipulations of the
uninformed reader in sneaky marketing papers, I still consider it bad and
inappropriate style.