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

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