"John Reimer" <brk_6502@yahoo.com> wrote in message news:pan.2004.07.25.06.30.45.581020@yahoo.com...
> > 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?

Heaven knows I disagree with Dr. Stroustrup on many points. However, this is a case where I agree with him. I am not simply doing it that way because Dr. Stroustrup did it that way.

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

I followed this aspect of C++ because I found the argument in favor of it compelling, and since D is a refactoring of C++ and not Java, it gives greater weight to C++ behavior over Java behavior.

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

Java explicitly differs from C++ in this regard. Kris is arguing for Java lookup/overriding rules. I see no reason that Java should be always be the right one to imitate, either <g>.

"Walter"  wrote .
> 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:

1)  You'll forgive me Walter, for saying that I think you may just be mistaken in terms of the time period. Recall that you sent me the prototype Interface-enabled D compiler (other than COM), and it most certainly did not have this "Contract Resolution" ability enabled.

2) the example below makes a comment about Interfaces not being inherited. In D they *are* inherited! I've used that time and time again to work around the ever-persistent "diamond interface" related bugs.

3) the example below is built explicitly to circumvent /some/ type system. Also, it /could/ be argued that the example below produces a valid and predictable result. Regardless, Because D interfaces *are* inherited this is quite possibly a moot point entirely.

4) Do you not think this supposed type hole can be worked out in some other way? The trade-off is, well, I've already documented all the fallout from this decision.

5) While not wishing to harp on about Java ~ if this is such a problem, how does Java avoid it? It manages perfectly well, thank-you-very-much. D is so supposed to be so much better, right? This "decoupled contract" aspect is a major player in the Interface arsenel: please do not underestimate it. Here's an extract from my revised document:

"An Interface is nothing more than a contract. One of the great things about this notion is there's no implicit binding between the Interface and how it is actually fulfilled by the implementation. It is perfectly legitimate for a class to satisfy its contractual obligation in any way it sees fit; including via local methods, via public methods exposed through inheritance, via some base class, via an implemented abstract class, or any combination thereof. That is, the contract can be declared and fulfilled entirely by any particular class, aggregated piecemeal through inheritance, or be inherited itself through some super-class derivation.

To stipulate otherwise would enforce an implementation restriction that has no bearing whatsoever upon the contract itself. Under those terms, satisfying the contract would mean ensuring the design of your exposed class hierarchy matches exactly that of the Interface hierarchy - thus negating the intentionally decoupled nature of the contract."

Sorry Walter; there's just too many flaws in your statement to be convincing.

- Kris




>
> --------------------------------------------
> 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"  wrote ...
> Java explicitly differs from C++ in this regard. Kris is arguing for Java lookup/overriding rules. I see no reason that Java should be always be the right one to imitate, either <g>.

I am, huh? I thought I was advocating logical progression and continuity of behavior. This is /not/ something the D compiler currently has with respect to name resolution. Far from it actually ... what about imitating ease-of-use and common sense, Walter? <g>

I really think you need to show us some good code examples of why this is so much to our benefit, and not a maligned detraction instead.

If you can't fix imports to act as though outer-scope methods have somehow been "aliased into scope", then I humbly suggest you make it illegal to allow an import within the class scope.

I do that all the time for one good reason: all version(linux) and
version(Win32) stuff should be isolated together wherever possible. This
means I deliberately place imports inside class boundaries, because it is
the most maintainable way to set things up (you don't have to go grubbing
around trying to find/edit some reference elsewhere). If you make inner
imports illegal, then you'll ultimately make the code less maintainable. But
even I would grudgingly admit that's better than the obnoxious behavior
currently
exposed.

Of course, one or the other really has to be remedied: forward references or, uhhhh, smarter name resolution ... current versions of  DMD do not cut it for the former or the latter.

- Kris


"Walter" <newshound@digitalmars.com> wrote in message news:cdvimn$1o5c$1@digitaldaemon.com...
>
> "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.
>
>

In article <pan.2004.07.25.06.30.45.581020@yahoo.com>,
 John Reimer <brk_6502@yahoo.com> wrote:

> 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

If the alias thing is a bug, I disagree on all counts.  I like the option of not including the overloaded members which I didn't overload. There may be cases where a child class does not want those to be inherited.   Which is allowed by the current method. If it becomes the default behavior to inherit them, you'd need to have some kind of convention to get RID of them.

In article <cdvrf1$1unf$1@digitaldaemon.com>, Kris says...
>
>"Walter"  wrote ...
>> Java explicitly differs from C++ in this regard. Kris is arguing for Java lookup/overriding rules. I see no reason that Java should be always be the right one to imitate, either <g>.
>
>I am, huh? I thought I was advocating logical progression and continuity of behavior. This is /not/ something the D compiler currently has with respect to name resolution. Far from it actually ... what about imitating ease-of-use and common sense, Walter? <g>

This discussion would probably be better continued once the associated compiler bugs have been fixed.  Without the ability to offer practical working examples of how the existing scheme does not work, I think there's the potential for a bit of confusion over specifics.

Sean

That would be a fair point Sean, but the issue is not about the bugs surrounding alias; it's about the necessity of its arcane and non-intuitive use. My document deliberately avoided pointing out the bugs still there, to avoid exactly this kind of confusion. It doesn't change the basic premise ... <g>

I'm still waiting for Walter (or anyone) to provide a good code example or two that shows exactly why D needs this. Without that, the vague argument about what B.S. believes holds no water whatsoever with respect to D -- in other words, there is /still/ no solid counter-point to examine. It's in all our interests to get this resolved properly ~ so bring on the examples I say!

:-)


"Sean Kelly" <sean@f4.ca> wrote in message news:ce0s5l$2gne$1@digitaldaemon.com...
> In article <cdvrf1$1unf$1@digitaldaemon.com>, Kris says...
> >
> >"Walter"  wrote ...
> >> Java explicitly differs from C++ in this regard. Kris is arguing for
Java
> >> lookup/overriding rules. I see no reason that Java should be always be
the
> >> right one to imitate, either <g>.
> >
> >I am, huh? I thought I was advocating logical progression and continuity
of
> >behavior. This is /not/ something the D compiler currently has with
respect
> >to name resolution. Far from it actually ... what about imitating ease-of-use and common sense, Walter? <g>
>
> This discussion would probably be better continued once the associated
compiler
> bugs have been fixed.  Without the ability to offer practical working
examples
> of how the existing scheme does not work, I think there's the potential
for a
> bit of confusion over specifics.
>
> Sean
>
>

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

Very true, I tried compiling DFL with .94 ( or some such ) and it died with tons of forward refrences, while .96 worked without a hitch.  I Think that old FR workaround should be abandoned ( thank goodness ).

Charlie


In article <cdvimn$1o5c$1@digitaldaemon.com>, Walter says...
>
>
>"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.
>
>

Walter wrote:

> You describe it as "The latter is utter nonsense, and smacks of either an
> implementation-specific hack or a half-baked and headless C-style
> implementation of method hiding." However, consider the following C++
> program:
> 
> --------------------------------------
  ...
> -------------------------------------------
> Now uncomment the 'using' declaration, and the program will compile
> successfully and produce the 1, 2, 3 output. Therefore, D uses
> overloading/hiding rules that are completely analogous to C++. I've read a
> lot of critiques of C++, and this has not been mentioned. Or perhaps my C++
> compiler has an egregious fault in it, but I find it hard to believe it
> would have lasted this long with such a fundamental flaw <g>.
> 

I believe this example is misleading. The name resolution is important in C++ only because struct B might inherit from a second struct, say Y, which also implements 'int foo(int i)'. C++ cannot (and would not) be critiqued because it must resolve against multiple super classes. Using C++ rules designed to select from a multiple inheritance hierarchy in D does not make sense.

I do not believe it is possible to justify hiding anything in a single inheritance language.

Walter wrote:

> I followed this aspect of C++ because I found the argument in favor of it
> compelling, and since D is a refactoring of C++ and not Java, it gives
> greater weight to C++ behavior over Java behavior.
---
> Java explicitly differs from C++ in this regard. Kris is arguing for Java
> lookup/overriding rules. I see no reason that Java should be always be the
> right one to imitate, either <g>.

IMHO, C++ is *not* the language you want to imitate when it comes to OOP issues. Java and Eiffel are better suited; Java because the single inheritance/interface model is used by D, Eiffel because it seems to work even if everything is possible.

Lars Ivar Igesund