View mode: basic / threaded / horizontal-split · Log in · Help
July 25, 2004
Re: The Alias peek-a-boo Game
"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.
July 25, 2004
Re: The Alias peek-a-boo Game
"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.
July 25, 2004
Re: The Alias peek-a-boo Game
"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.
July 25, 2004
Re: The Alias peek-a-boo Game
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"
>
>
>
July 25, 2004
Re: External Names
"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.
July 25, 2004
Re: Three notable problems with method name resolution
"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!
July 25, 2004
Re: Satisfying Interface Requirements
"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;
}

---------------------------------------------------------------
July 25, 2004
Re: The Alias peek-a-boo Game
"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
July 25, 2004
Re: The Alias peek-a-boo Game
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
July 25, 2004
Re: External Names
> 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.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home