• Kris (33/33) Apr 17 2004 Is there a way to specifically invoke a method implemented within the
• Walter (4/37) May 26 2004 The way to do that is to have two functions, a "get()" which is virtual
• Kris (10/57) May 26 2004 Thanks Walter; but that's hardly what I'd call "language support" . A...
• Norbert Nemec (12/18) May 26 2004 It is not such a common thing that you could expect special features in
• Kris (13/18) May 26 2004 efficiency
• Walter (4/6) May 26 2004 enclosing
• Hauke Duden (13/24) May 26 2004 I think that'd be a mistake. There is a programming style (often used by...
• Kris (29/43) May 26 2004 Perhaps I misunderstand you HD, but I think we're saying the same thing
• Walter (8/19) May 26 2004 I think the this.member() being direct, rather than virtual, call is wha...
• Hauke Duden (20/46) May 27 2004 If that is true then it proves my point. I have been programming on and
• Walter (3/3) May 27 2004 I made a mistake. Java does not allow this.method() to access overridden
• Ant (6/9) May 27 2004 in java you can do:
• Andy Friesen (3/20) May 26 2004 I second this, since you could do typeof(this).method();
• Ant (7/54) May 27 2004 I'm afraid that is the correct answer.
• Kris (13/71) May 27 2004 It is a real-life scenario Antonio, but one that can be (has been) chang...
• Ant (9/16) May 27 2004 (What would you call it? "sometimes polimorphic"?)
• Kris (10/14) May 27 2004 The only way to be absolutely sure someone won't screw with a class
• Ant (9/20) May 28 2004 Yes, and I don't think we should have a way to do it.

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

Is there a way to specifically invoke a method implemented within the
enclosing class? One can explicitly invoke the super class implementation
(via 'super.'), but what about this scenario:

class A
{
       private Object[char[]]  map;

       Object get (char[] key)
       {
            return map[key];
       }

       Object extract (char[] key)
       {
            // we want to invoke get() from this class;
            // not from some subclass implementation
            Object o = this.get (key);
             if (o)
                 delete map [key];
             return o;
       }
}


class B : A
{
      Object get (char[] key)
      {
            Object o = super.get (key);
            // do all kinds of other stuff ...
      }
}

When instantiated as a Class B instance, A.extract() does *not* want to
invoke the overridden version of get() ... it just wants to use the known
version within its containing class ...

Can D handle this case?

- Kris

"Walter" <newshound digitalmars.com> writes:

The way to do that is to have two functions, a "get()" which is virtual
which calls a private "Aget()". Then, instead of this.get(), use Aget().

"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c5ql8n$4ot$1 digitaldaemon.com...
 Is there a way to specifically invoke a method implemented within the
 enclosing class? One can explicitly invoke the super class implementation
 (via 'super.'), but what about this scenario:

 class A
 {
        private Object[char[]]  map;

        Object get (char[] key)
        {
             return map[key];
        }

        Object extract (char[] key)
        {
             // we want to invoke get() from this class;
             // not from some subclass implementation
             Object o = this.get (key);
              if (o)
                  delete map [key];
              return o;
        }
 }


 class B : A
 {
       Object get (char[] key)
       {
             Object o = super.get (key);
             // do all kinds of other stuff ...
       }
 }

 When instantiated as a Class B instance, A.extract() does *not* want to
 invoke the overridden version of get() ... it just wants to use the known
 version within its containing class ...

 Can D handle this case?

 - Kris

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

Thanks Walter; but that's hardly what I'd call "language support" <g>. And
it's not very efficient unless it happens to also be inline-able, assuming
development constraints are relaxed enough to permit -inline usage ...

Is it not possible to bind explicit use of "this.method()" to the enclosing
class, rather then any derivative overload?

- Kris


"Walter" <newshound digitalmars.com> wrote in message
news:c92nkt$2mun$2 digitaldaemon.com...
 The way to do that is to have two functions, a "get()" which is virtual
 which calls a private "Aget()". Then, instead of this.get(), use Aget().

 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c5ql8n$4ot$1 digitaldaemon.com...
 Is there a way to specifically invoke a method implemented within the
 enclosing class? One can explicitly invoke the super class


implementation
 (via 'super.'), but what about this scenario:

 class A
 {
        private Object[char[]]  map;

        Object get (char[] key)
        {
             return map[key];
        }

        Object extract (char[] key)
        {
             // we want to invoke get() from this class;
             // not from some subclass implementation
             Object o = this.get (key);
              if (o)
                  delete map [key];
              return o;
        }
 }


 class B : A
 {
       Object get (char[] key)
       {
             Object o = super.get (key);
             // do all kinds of other stuff ...
       }
 }

 When instantiated as a Class B instance, A.extract() does *not* want to
 invoke the overridden version of get() ... it just wants to use the


known
 version within its containing class ...

 Can D handle this case?

 - Kris

Norbert Nemec <Norbert.Nemec gmx.de> writes:

Kris wrote:

 Thanks Walter; but that's hardly what I'd call "language support" <g>.

It is not such a common thing that you could expect special features in
helping you to do so. Any any special feature would probably be not much
simpler than the current solution.

 And
 it's not very efficient unless it happens to also be inline-able, assuming
 development constraints are relaxed enough to permit -inline usage ...

Of course it is simple to inline such a thing. The routine that has to be
inlined is private, so it is in the same module as the calling routine. If
the outer routine is nothing but a wrapper, why should it not be inlinable?

And if you try to work without -inline, you should not expect any efficiency
anyway.

 Is it not possible to bind explicit use of "this.method()" to the
 enclosing class, rather then any derivative overload?

That would be rather artificial: "this" has a certain type and using
".method()" on this type has a certain meaning. Changing this meaning in
that special case will cause all kinds of problems.

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

I agree in general Norbert, but

"Norbert Nemec" wrote
 And if you try to work without -inline, you should not expect any

efficiency
 anyway.

That's a bit draconian <g>

 That would be rather artificial: "this" has a certain type and using
 ".method()" on this type has a certain meaning. Changing this meaning in
 that special case will cause all kinds of problems.

I seem to recall using exactly this syntax in Java to resolve this very
issue. In other words, prefixing a method call with "this." constrains the
Java call to within the enclosing class. This is really very helpful when
you are implementing an Interface, but want to avoid clashing with any
potential subclass implementation. I'm not sure that it does change the
meaning of "this." at all, but I guess Walter has the definitive word on
that ...

Cheers,

- Kris

"Walter" <newshound digitalmars.com> writes:

"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c92pp0$2qsf$1 digitaldaemon.com...
 Is it not possible to bind explicit use of "this.method()" to the

enclosing
 class, rather then any derivative overload?

On second thought, you're right. I'll make the change.

Hauke Duden <H.NS.Duden gmx.net> writes:

Walter wrote:
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c92pp0$2qsf$1 digitaldaemon.com...
 
Is it not possible to bind explicit use of "this.method()" to the

 
 enclosing
 
class, rather then any derivative overload?

 
 
 On second thought, you're right. I'll make the change.


I think that'd be a mistake. There is a programming style (often used by 
JAVA programmers) that does not use any prefixes for member variables. 
Instead, if the name of a member variable should conflict with a local 
variable, these people use this.varname to access the member.

The same should be true for methods, especially since D supports local 
methods. It is also the only consistent way. "this" is a reference to 
the current object, so <reference>.method() should behave the same, no 
matter if you use a reference variable or "this". Special handling of 
"this" will just make everything more complicated and harder to understand.

If you need to call a method in a fully qualified way, why not use the 
normal way? I.e. CLASSNAME.method() ?

Hauke

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

Perhaps I misunderstand you HD, but I think we're saying the same thing
here. The use of "this." with a member variable is being explicit about
which instance is referred to (when there's confusion with an argument/auto
of the same name). The same should hold true with member functions.

The "super." prefix is present for similar reasons when you want to be
explicit about a superclass member variable or method. As it stands right
now, the "this." prefix is explicit regarding member variables but not
methods (because it currently includes subclass methods also). I'm asking
that it be changed such that "this." behaves the same for both variables and
methods.

The default "fully virtualized" behavior (sans prefix) is not affected by
this whatsoever.

As noted before, this situation crops up mostly when implementing an
Interface and you want to constrain behavior from any given superclass to
within that particular superclass only. That is, the interface method(s)
might be reimplemented by a subclass, but the *internal* behavior of the
original implementing class remains constant because explicit method calls
invoke its own methods rather than having them overridden. Not being able to
explicitly state "I want *that* particular method" can lead to all kinds of
nasty bugs when someone (at a later date) derives a superclass with methods
of the same signature ... this is perhaps a dark-side of treating methods as
virtual by default?

 If you need to call a method in a fully qualified way, why not use the
 normal way? I.e. CLASSNAME.method() ?

Surely that would assume the method were static? It would certainly be nice
to fully qualify the method in some fashion, other than "super." or "this.";
I vaguely recall Java does that with some ClassName.this.method()
incantation.

- Kris


"Hauke Duden" wrote:
 I think that'd be a mistake. There is a programming style (often used by
 JAVA programmers) that does not use any prefixes for member variables.
 Instead, if the name of a member variable should conflict with a local
 variable, these people use this.varname to access the member.

 The same should be true for methods, especially since D supports local
 methods. It is also the only consistent way. "this" is a reference to
 the current object, so <reference>.method() should behave the same, no
 matter if you use a reference variable or "this". Special handling of
 "this" will just make everything more complicated and harder to

understand.
 If you need to call a method in a fully qualified way, why not use the
 normal way? I.e. CLASSNAME.method() ?

 Hauke

"Walter" <newshound digitalmars.com> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c939g8$h6c$1 digitaldaemon.com...
 I think that'd be a mistake. There is a programming style (often used by
 JAVA programmers) that does not use any prefixes for member variables.
 Instead, if the name of a member variable should conflict with a local
 variable, these people use this.varname to access the member.

I think the this.member() being direct, rather than virtual, call is what
Java does, and I haven't seen it listed as a mistake in Java's design.

 The same should be true for methods, especially since D supports local
 methods. It is also the only consistent way. "this" is a reference to
 the current object, so <reference>.method() should behave the same, no
 matter if you use a reference variable or "this". Special handling of
 "this" will just make everything more complicated and harder to

understand.

It already does this with super.member, this.member just makes it more
consistent (depending on how you look at it).

 If you need to call a method in a fully qualified way, why not use the
 normal way? I.e. CLASSNAME.method() ?

That usually caused problems for me when cutting & pasting code :-(

Hauke Duden <H.NS.Duden gmx.net> writes:

Walter wrote:
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c939g8$h6c$1 digitaldaemon.com...
 
I think that'd be a mistake. There is a programming style (often used by
JAVA programmers) that does not use any prefixes for member variables.
Instead, if the name of a member variable should conflict with a local
variable, these people use this.varname to access the member.

 
 
 I think the this.member() being direct, rather than virtual, call is what
 Java does, and I haven't seen it listed as a mistake in Java's design.

If that is true then it proves my point. I have been programming on and 
off in JAVA for the last half a dozen years and I didn't know that. I 
don't use the "this.XXX" style, so that's why I never tripped about 
this, but if I had read "this.method()" I would sure as hell have 
assumed it to be the same as

CLASSNAME ref=this;
ref.method();

It is hugely inconsistent if it isn't!


The same should be true for methods, especially since D supports local
methods. It is also the only consistent way. "this" is a reference to
the current object, so <reference>.method() should behave the same, no
matter if you use a reference variable or "this". Special handling of
"this" will just make everything more complicated and harder to

 
 understand.
 
 It already does this with super.member, this.member just makes it more
 consistent (depending on how you look at it).

But super is not a reference - if it was then it would be the same as 
"this", wouldn't it? It is an alias for the base class name.

If you need to call a method in a fully qualified way, why not use the
normal way? I.e. CLASSNAME.method() ?

 
 
 That usually caused problems for me when cutting & pasting code :-(

Urrrgh. You publicly admit to frequently cutting & pasting? Don't you 
know that it is the greatest sin in programming? ;)

But seriously, it doesn't have to be the class name. typeof(this), as 
someone else mentioned, could be an alternative way to do this (using 
the classname should still be possible, though). As long as "this" stays 
a normal reference.

Besides, when you only have super and this for qualification then you 
still can't access overloaded methods that are lower in the hierarchy.


Hauke

"Walter" <newshound digitalmars.com> writes:

I made a mistake. Java does not allow this.method() to access overridden
methods. So I'll back out that change - we'll go with the
typeof(this).method().

Ant <Ant_member pathlink.com> writes:

In article <c94duq$25kf$1 digitaldaemon.com>, Walter says...
I made a mistake. Java does not allow this.method() to access overridden
methods. So I'll back out that change - we'll go with the
typeof(this).method().

in java you can do:
ClassName.this.method();

typeof(this).method(); looks like a static method to me:
not really what we a talking about.

Ant

Andy Friesen <andy ikagames.com> writes:

Hauke Duden wrote:

 Walter wrote:
 
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c92pp0$2qsf$1 digitaldaemon.com...

 Is it not possible to bind explicit use of "this.method()" to the
 enclosing  class, rather then any derivative overload?

 On second thought, you're right. I'll make the change.

 
 I think that'd be a mistake. There is a programming style (often used by 
 JAVA programmers) that does not use any prefixes for member variables. 
 Instead, if the name of a member variable should conflict with a local 
 variable, these people use this.varname to access the member.
 
 If you need to call a method in a fully qualified way, why not use the 
 normal way? I.e. CLASSNAME.method() ?

I second this, since you could do typeof(this).method();

  -- andy

Ant <Ant_member pathlink.com> writes:

In article <c92nkt$2mun$2 digitaldaemon.com>, Walter says...
The way to do that is to have two functions, a "get()" which is virtual
which calls a private "Aget()". Then, instead of this.get(), use Aget().

I'm afraid that is the correct answer.
if get() if not suppouse to be overwritten make it final or private.
You want to through away one of the main OO design features.
I say that your implementation design should be reviwed, not the language.
is this a real life scenario you need to support?

Ant

"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c5ql8n$4ot$1 digitaldaemon.com...
 Is there a way to specifically invoke a method implemented within the
 enclosing class? One can explicitly invoke the super class implementation
 (via 'super.'), but what about this scenario:

 class A
 {
        private Object[char[]]  map;

        Object get (char[] key)
        {
             return map[key];
        }

        Object extract (char[] key)
        {
             // we want to invoke get() from this class;
             // not from some subclass implementation
             Object o = this.get (key);
              if (o)
                  delete map [key];
              return o;
        }
 }


 class B : A
 {
       Object get (char[] key)
       {
             Object o = super.get (key);
             // do all kinds of other stuff ...
       }
 }

 When instantiated as a Class B instance, A.extract() does *not* want to
 invoke the overridden version of get() ... it just wants to use the known
 version within its containing class ...

 Can D handle this case?

 - Kris

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

It is a real-life scenario Antonio, but one that can be (has been) changed.
It does tend to crop up though, especially when working with interfaces (the
tendency is to implement the interface methods, and then use them within the
enclosing class for whatever purpose without regard to the fact those
methods may well be overridden at some future point).

I guess it's perhaps an OO boundary condition, since I could personally make
an argument for both perspectives. Having said that, I think Walter has this
condition covered for those who wish to be extra careful.

 - Kris


"Ant" <Ant_member pathlink.com> wrote in message
news:c95b2i$1a8u$1 digitaldaemon.com...
 In article <c92nkt$2mun$2 digitaldaemon.com>, Walter says...
The way to do that is to have two functions, a "get()" which is virtual
which calls a private "Aget()". Then, instead of this.get(), use Aget().

 I'm afraid that is the correct answer.
 if get() if not suppouse to be overwritten make it final or private.
 You want to through away one of the main OO design features.
 I say that your implementation design should be reviwed, not the language.
 is this a real life scenario you need to support?

 Ant

"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c5ql8n$4ot$1 digitaldaemon.com...
 Is there a way to specifically invoke a method implemented within the
 enclosing class? One can explicitly invoke the super class



implementation
 (via 'super.'), but what about this scenario:

 class A
 {
        private Object[char[]]  map;

        Object get (char[] key)
        {
             return map[key];
        }

        Object extract (char[] key)
        {
             // we want to invoke get() from this class;
             // not from some subclass implementation
             Object o = this.get (key);
              if (o)
                  delete map [key];
              return o;
        }
 }


 class B : A
 {
       Object get (char[] key)
       {
             Object o = super.get (key);
             // do all kinds of other stuff ...
       }
 }

 When instantiated as a Class B instance, A.extract() does *not* want to
 invoke the overridden version of get() ... it just wants to use the



known
 version within its containing class ...

 Can D handle this case?

 - Kris

Ant <Ant_member pathlink.com> writes:

In article <c95ctf$1d2a$1 digitaldaemon.com>, Kris says...
It is a real-life scenario Antonio, but one that can be (has been) changed.
It does tend to crop up though, especially when working with interfaces (the
tendency is to implement the interface methods, and then use them within the
enclosing class for whatever purpose without regard to the fact those
methods may well be overridden at some future point).

ah... code first and ask question later... ;)

I guess it's perhaps an OO boundary condition, since I could personally make
an argument for both perspectives.

(What would you call it? "sometimes polimorphic"?)

That is the function of "final" (for methods) in java.
Do we have it in D?
if not we will need it.

(I was on the D specs but couldn't find it. The attribute "final"
exists but is not described)

Ant

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

"Ant" wrote:
 ah... code first and ask question later... ;)

The only way to be absolutely sure someone won't screw with a class
implementation is to make everything private <g>. One can essentially
guarantee someone will (deliberately or accidently) find a way to subvert
any initial assumptions. A reasonable approach to avoid much of this is to
make two version of each clearly abusable class: an immutable, plus a
mutable subclass. Although that doesn't have much (if any) bearing on the
current topic.


 (What would you call it? "sometimes polimorphic"?)

"AC/DC" :-)  Ok, Ok, this is a serious topic.


 That is the function of "final" (for methods) in java.
 Do we have it in D?

Yep, D does support "final" methods.

Ant <Ant_member pathlink.com> writes:

In article <c95h7a$1jit$1 digitaldaemon.com>, Kris says...
"Ant" wrote:
 ah... code first and ask question later... ;)

The only way to be absolutely sure someone won't screw with a class
implementation is to make everything private <g>. One can essentially
guarantee someone will (deliberately or accidently) find a way to subvert
any initial assumptions. A reasonable approach to avoid much of this is to
make two version of each clearly abusable class: an immutable, plus a
mutable subclass. Although that doesn't have much (if any) bearing on the
current topic.


 (What would you call it? "sometimes polimorphic"?)

"AC/DC" :-)  Ok, Ok, this is a serious topic.

Yes, and I don't think we should have a way to do it.
either a method is virtual or it's not.
well, it's more of a feel. I didn't do any deep analizes.
But I think I should the more I think of this the more dangerous
it seems.

I'll try read Walter's posts here (tonight) to see if an emergency
post against this is necessary.

Ant