"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdu9ov$162i$1@digitaldaemon.com...
> Sean; would you mind explaining the benefits of those particular
resolution
> rules to me please? While I may be both blind and stupid, I completely
fail
> to see where the value lies, and no-one has specified what they are.

Stroustrup has laid them out in chapter 13.1 of the "The Annotated C++ Reference Manual." The general rule for overloading is that a name is looked up first, and then overload resolution is applied. Stroustrup rejects the idea of ignoring scope issues when doing overload resolution. He argues that it would be surprising in a deeply nested heirarchy of class derivation, that a user of a derived class would have to know too much detail about a base class that may be hidden. Also, he shows how surprising errors can creep in, such as if a function in base class B copies only the B part of an object, but was inadvertantly called with an instance of D that didn't override each of those B functions properly.

"J C Calvarese" <jcc7@cox.net> wrote in message news:cduh40$18fr$1@digitaldaemon.com...
> As I also mentioned in the other thread (http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/7011), the aliasing works if it's AFTER the new types. I don't know if it should be that way or has to be that way, but that's how it works in DMD 0.96.

That's a compiler bug.

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdu57d$1474$1@digitaldaemon.com...
> I implore you to please explain why it's so beneficial to hide these signatures, from the developers perspective? At least that would provide a solid counter-point.

1) I find Stroustrup's argument in the ARM 13.1 (outlined in another
message) reasonable.

2) In my experience with C++, this behavior has not caused an outcry and is not listed in any diatribes I've seen as one of the broken features of C++.

3) So I am reluctant to break with the C++ rule on this.

The rule to apply is straightforward - look up the name, *then* apply overload resolution.

And that is a compiler bug!

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdu5f0$14dm$1@digitaldaemon.com...
> Also, please note that following doesn't even compile:
>
> class Writer
> {
>         void put (bit x){}
>         void put (int x){}
> }
>
> class MyWriter : Writer
> {
>         alias Writer.put put;
>
>         void put (bit x){}
> }
>
> "function put conflicts with MyWriter.put"
>
>
>

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdu94m$15t6$1@digitaldaemon.com...
> That's wonderful! However, you avoided a significant attribute of the
issue
> in that signature matching is abandoned during the matching process. That is, there is no notion of looking to see if there's a better 'signature' match. As I stated; the import of those two linux function names blows
away
> the other signatures. This seems like a half-way house, but I can
certainly
> /imagine/ why your compiler might choose not to do that.

It's following the rule that name lookup happens first, *then* overload resolution. Signatures only have relevance to overload resolution, and no relevance to name lookup. I worry that if I start breaking this rule for special cases here and there, the resulting confusion would be far, far worse, and would relegate D to an "experts only" language. I think we're served better by simple, universally applied rules even if we're not happy with the result in some odd cases.


> Perhaps the most serious problem is that said issue does not manifest
within
> FileConduit itself. It's only when a call is placed (from some other
module)
> to either read() or close() that the compile breaks. I thought John Reimer
> stated it rather well in his post (7/24/2004,12:41) on the subject.

By importing a bunch of names into a scope, well, those names get found in that scope. Put the import outside of that scope!

> Lastly: You, and many others, are acutely aware of the problems related to forward references. Placing the import inside the class scope is currently the /only/ way to resolve some of those. Now we have to move imports
outside
> the class-scope just so we can call certain methods therein. Do you see
the
> conflict here?

The later DMD versions do a better job of handling forward references. If I have specific examples of where that still fails, I can work on that. Putting the imports in the class scope is, I believe, the wrong solution, and even worse would be trying to hammer it to fit.


> What I personally find strange, Walter, is that such conflicts just don't seem to register as valid problems. At least now we know what the compiler does.

What I interpret is going on here is that imports inside classes are attempts at working around a forward reference problem. The solution is to get at the forward reference problem.

"Vathix" <vathixSpamFix@dprogramming.com> wrote in message news:cdta9c$q1c$1@digitaldaemon.com...
> Satisfying Interface Contracts:
> From class.html#interface it says "A reimplemented interface must
implement
> all the interface functions, it does not inherit them from a super class."
I
> don't see why you're specifying to (re)implement IFoo without
reimplementing
> it. You can't specify a base class twice, why are you doing it for an interface? It just so happens that specifying to implement an interface
has
> an added feature for reimplementing. In fact, when I tried it with a
class,
> the compiler crashed!

I hope you send me the example that caused a crash!

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdu77l$158f$1@digitaldaemon.com...
> How about it Walter? I'd really, really, like to understand why
super-class
> methods are explicitly denied from satisfying a sub-class contract. At
least
> then there'd be something to discuss vis-a-vis pro & con ...

Sure. D originally worked the way you suggest. However, this message to me by Joe Battelle convinced me otherwise. It's a bit complicated, but essentially it's to close up a type hole:

--------------------------------------------
The fact that interfaces are snapshots and not inherited from class to
subclass
can really mess you up sometimes.  Just tacking on the interface at each
level
in the hierarchy doesn't work either--you get a unique interface each time.
Casting to a superclass before casting to the interface that the derived
type
supports can alter which version of the interface is called.  The spec
doesn't
say much about this.

Are we stuck with this feature of interfaces or will they be inheritable at
some
point?

Example code:
-------------
import c.stdio;

interface D {
abstract int foo();
}

class A : D {
int foo() { return 1; }
}

class B : A, D { //carry the D's, 'cause they're not inherited
//this should tell you something's up :)
//A's foo is taken to satisfy D.
//a cast(D) on a B will always use this foo
//even if the B is actually a further derived type with overloaded foo()
}

class C : B, D {
int foo() { return 2; }
}

int main (char[][] args)
{
C c = new C;
A a = (A) c;
int j = a.foo(); // 2
B b = (B) c;
int k = b.foo(); // 2
D d1 = (D) c;
int l = d1.foo(); // 2
D d2 = (D) b;
int m = d2.foo(); // 1 Gotcha!!!  b.foo() not equal to (D)b.foo()

//prints 2 2 2 1
printf("%d %d %d %d", j, k, l, m);

return 0;
}

---------------------------------------------------------------

"Walter" <newshound@digitalmars.com> wrote in message news:cdvhgv$1nf1$1@digitaldaemon.com...
>
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdu9ov$162i$1@digitaldaemon.com...
> > Sean; would you mind explaining the benefits of those particular
> resolution
> > rules to me please? While I may be both blind and stupid, I completely
> fail
> > to see where the value lies, and no-one has specified what they are.
>
> Stroustrup has laid them out in chapter 13.1 of the "The Annotated C++ Reference Manual." The general rule for overloading is that a name is
looked
> up first, and then overload resolution is applied. Stroustrup rejects the idea of ignoring scope issues when doing overload resolution. He argues
that
> it would be surprising in a deeply nested heirarchy of class derivation, that a user of a derived class would have to know too much detail about a base class that may be hidden. Also, he shows how surprising errors can creep in, such as if a function in base class B copies only the B part of
an
> object, but was inadvertantly called with an instance of D that didn't override each of those B functions properly.
>
>

That is indeed the C++ view. However you forget a number of things:

1) D is better in so many ways than C++. It says so right there in the comparison charts ... <g>

2) C++ had to deal with multiple inheritance ~ I imagine that's a big factor in the above statement. D (and Java) do not. Notice how Java dispensed with the 'alias' notion completely, and did not pay this 'Stroustrup Tax' in any shape or form.

3) Aliasing method names is truly non-intuitive. It stands out like a sore thumb within D as a kludge. It does not matter from whence it came, or what supposed pedigree it has ~ so many other things in D are completely natural.

4) You may find that a required use of  "override" would alleviate some of those Stroustrup concerns.

5) You are at least as smart as B.S., and can do much better than this. I can't help but be entirely suspicious about the B.S. Gospel applying in the same manner.

I challenge you, Walter, to exceed C++ in this respect also.

I further challenge you to provide a reasonable D example showing where this kind of alias thing is actually beneficial to the D programmer. If you cannot do that, then this Stroustrup argument holds no water whatsoever. Since we're all required to spend a bunch of time whittling down code in bug reports for you, I think it's only fair you do the same in return with respect to issues like this. I mean, if the value of alias is so obvious, how much effort would a few good examples really take?

Regards;

- Kris

On Sat, 24 Jul 2004 22:48:51 -0700, Walter wrote:

> 
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdu57d$1474$1@digitaldaemon.com...
>> I implore you to please explain why it's so beneficial to hide these signatures, from the developers perspective? At least that would provide a solid counter-point.
> 
> 1) I find Stroustrup's argument in the ARM 13.1 (outlined in another
> message) reasonable.

As brilliant as he is, could Stroustrup actually be wrong on the matter? Or to put it another way, D is not C++ so why do we have to follow Stroustrup's conventions within a language Stroustrup did not design?

> 2) In my experience with C++, this behavior has not caused an outcry and is not listed in any diatribes I've seen as one of the broken features of C++.

D is a different language, and this issue is now causing an
outcry here that you deny exists elsewhere.  The language seems to be
different enough (perhaps because of so many features similar to Java)
that this is indeed now an issue. The fact that D has different features
from C++ makes a solution to these problems important to the language's
future (even if they apparently weren't significant in C++).  Also C++ has
it's own community of personalities. The fact that complaints might be
nonexistent in that community doesn't imply that the issue isn't important
in the D community.

What it comes down to is that it seems you have decided to follow C++ standards either for convenience or preference.  I guess that's good to know.

> 3) So I am reluctant to break with the C++ rule on this.
> 
> The rule to apply is straightforward - look up the name, *then* apply overload resolution.

This appears to be a Java verses C++ debate.  Does java define name lookup
rules differently (someone indicated so in another message, I believe)?
If so, why is the C++ way better then the java way?  The C++
model shouldn't always be the right one to imitate, should it?

As it stands, I think your adoption of C++ name lookup rules into the D language has made it confusing.  Is that what happens when you mix C++ and Java ancestry?

I don't fully comprehend the nitty gritty details of this, but it makes for interesting debate! I just hope there's a useful resolution to it all.

Later,
John

> The later DMD versions do a better job of handling forward references. If I have specific examples of where that still fails, I can work on that. Putting the imports in the class scope is, I believe, the wrong solution, and even worse would be trying to hammer it to fit.
> 
> 
>> What I personally find strange, Walter, is that such conflicts just don't seem to register as valid problems. At least now we know what the compiler does.
> 
> What I interpret is going on here is that imports inside classes are attempts at working around a forward reference problem. The solution is to get at the forward reference problem.

I'm satisfied with this solution.  As long as forward reference issues can be settled, I'll have no problem putting imports external to classes (that's where I figure they should be anyway).  But fixing those forward reference errors will be a long, difficult road anyway because the complicated problems typically don't melt down to the simple examples you so admire.  I still don't like the way an import can override the way it does, but it obviously becomes a non-issue at this point if the necessity of the internal import is taken away.