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

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

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

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.

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

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

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

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

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

"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 :-(