Thanks Andy;

"Andy Friesen" <andy@ikagames.com> wrote in message news:c95aho$19gv$1@digitaldaemon.com...
> Kris wrote:
> > The alternative syntax "typeof(this)." would appear to conflict with the invocation of a static D method. That is, it appears to be the
equivalent of
> > a function rather than a delegate invocation. The initial request was in
the
> > context of a valid this-pointer, within an instantiated class instance.
This
> > infers a delegate approach.
>
> It can't be ambigious because the exact method being called can always be deduced from the argument types.
>
> class A {
>     void foo() { A.foo(9); } // unambigious.  A.foo(int) is not static,
> so 'this' is passed.
>     void foo(int x) { ... }
>
>     // static void foo(int x) { ... } // not allowed.  A already has a
> foo(int)
> }
>
>   -- andy

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> wrote in message news:c95ase$1a2u$1@digitaldaemon.com...
> In article <c959fd$17un$1@digitaldaemon.com>, Walter says...
> >
> >
> >> First, let's examine what Java does:
> >>
> >> Applying "this." or "Class.this." prefixes to Java methods does NOT constrain the invocation to the targeted class instance.
> >
> >Correct,  although I don't believe "Class.this" is valid java syntax.
> >
> My mistake, the sintax is valid.
>
> in "Class.this"
>
> the "Class" is an outer class or enclosing class,
> so not supported in D (I would like to say yet).

Thanks for the correction. I was reading from a pre-inner class java spec <g>.

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c95c1a$1bq0$1@digitaldaemon.com...
> class T1 {
> String s() { return "1"; }
> }
> class T2 extends T1 {
> String s() { return "2"; }
> }
> class T3 extends T2 {
> String s() { return "3"; }
> void test() {
> System.out.println("s()=\t\t"+s());
> System.out.println("super.s()=\t"+super.s());
> System.out.print("((T2)this).s()=\t");
> System.out.println(((T2)this).s());
> System.out.print("((T1)this).s()=\t");
> System.out.println(((T1)this).s());
> }
> }
> class Test {
> public static void main(String[] args) {
> T3 t3 = new T3();
> t3.test();
> }
> }
> which produces the output:
>
> s()= 3
> super.s()= 2
> ((T2)this).s()= 3
> ((T1)this).s()= 3

Try this:
    T1.s()

"Walter" <newshound@digitalmars.com> wrote in message
> Try this:
>     T1.s()

"non-static member cannot be referenced from a static context"

T1.this.s();

"not an enclosing class: T1"

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

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

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c95fm2$1hcn$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote in message
> > Try this:
> >     T1.s()
>
> "non-static member cannot be referenced from a static context"

Try it from a non-static member function.

> T1.this.s();
>
> "not an enclosing class: T1"
>
>

"Walter" <newshound@digitalmars.com> wrote in message
> > > Try this:
> > >     T1.s()
> >
> > "non-static member cannot be referenced from a static context"
>
> Try it from a non-static member function.

I'm totally confused as to what you're asking Walter; the error is saying to
me "s() is non-static (it certainly is) and you cannot invoke it from a
static context (T1.s)".

Unlike D, Java does not automatically imply a "this." for said syntax, so regardless of where you place the T1.s() it will treated as a static context. That's why I also added the "T1.this.s()" error message, so as to differentiate.

BTW, the error *was* actually produced from a non-static member function.

Am I losing my mind here?

- Kris

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c95spj$24u6$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote in message
> > > > Try this:
> > > >     T1.s()
> > >
> > > "non-static member cannot be referenced from a static context"
> >
> > Try it from a non-static member function.
>
> I'm totally confused as to what you're asking Walter; the error is saying
to
> me "s() is non-static (it certainly is) and you cannot invoke it from a
> static context (T1.s)".
>
> Unlike D, Java does not automatically imply a "this." for said syntax, so regardless of where you place the T1.s() it will treated as a static context. That's why I also added the "T1.this.s()" error message, so as to differentiate.

Hmm. I thought it did.

> BTW, the error *was* actually produced from a non-static member function.
>
> Am I losing my mind here?

How about this.T1.s() ?