"Walter" <walter@digitalmars.com> wrote in message news:bi6uhq$f05$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi6hdd$2rpa$3@digitaldaemon.com...
> > > Right. It is an error to override a final!
> > I have not overriden a final [the code was a little wrong]
>
> Correct, you did not. If you did, the compiler should have issued an
error.
>
but still you said `final` and non-virtual are the same.
but they are not quite, a final functions might have a vtbl entry (but will
never create a new one)
and a final function may be entered via the vtbl it is not always called
directly.
I accept that from the class where it is declared final and evokes can be
non-virtual but it does not break D semantics to always evoke member
functions via the vtbl.
you have chosen to optimise the final calls when you can (statically does
what Java Jit do).
or is that optimisation part of the D semantic spec ?

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi8aa9$2m7h$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:bi6uhq$f05$1@digitaldaemon.com...
> >
> > "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi6hdd$2rpa$3@digitaldaemon.com...
> > > > Right. It is an error to override a final!
> > > I have not overriden a final [the code was a little wrong]
> >
> > Correct, you did not. If you did, the compiler should have issued an
> error.
> >
> but still you said `final` and non-virtual are the same.
> but they are not quite, a final functions might have a vtbl entry (but
will
> never create a new one)

Yes.

> and a final function may be entered via the vtbl it is not always called
> directly.
> I accept that from the class where it is declared final and evokes can be
> non-virtual but it does not break D semantics to always evoke member
> functions via the vtbl.

Yes, but semantically the result is the same if called through the vtbl[] or directly.

> you have chosen to optimise the final calls when you can (statically does
> what Java Jit do).
> or is that optimisation part of the D semantic spec ?

The spec doesn't mandate any optimizations, although the semantics are defined to make many kinds of optimizations possible.

"Walter" <walter@digitalmars.com> wrote in message news:biat6p$g81$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi8aa9$2m7h$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bi6uhq$f05$1@digitaldaemon.com...
> > >
> > > "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bi6hdd$2rpa$3@digitaldaemon.com...
> > > > > Right. It is an error to override a final!
> > > > I have not overriden a final [the code was a little wrong]
> > >
> > > Correct, you did not. If you did, the compiler should have issued an
> > error.
> > >
> > but still you said `final` and non-virtual are the same.
> > but they are not quite, a final functions might have a vtbl entry (but
> will
> > never create a new one)
>
> Yes.

right, so will D support non virtual functions, the rest of your reply quite clearly states that `final` is not non - virtual, as you originally argued (when asked about non virtual functions).

>
> > and a final function may be entered via the vtbl it is not always called
> > directly.
> > I accept that from the class where it is declared final and evokes can
be
> > non-virtual but it does not break D semantics to always evoke member functions via the vtbl.
>
> Yes, but semantically the result is the same if called through the vtbl[]
or
> directly.
not quite, `this` can be null if invoked directly. (another reason I don't
like undefined features in langs [reason I do like the Java defined eval
order for all things])
the D semantice don't define anything about final, and do no do a null
pointer check if the call is optimised thus will behave differently on
different implementations of D.

>
> > you have chosen to optimise the final calls when you can (statically
does
> > what Java Jit do).
> > or is that optimisation part of the D semantic spec ?
>
> The spec doesn't mandate any optimizations, although the semantics are defined to make many kinds of optimizations possible.

Mike Wynn wrote:

> not quite, `this` can be null if invoked directly.

I guess not. Direct or VTable call has nothing to do with it - "this" can only be null if you didn't create an object you're calling it on.

-eye

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bikrug$j5f$1@digitaldaemon.com...
> Mike Wynn wrote:
>
> > not quite, `this` can be null if invoked directly.
>
> I guess not. Direct or VTable call has nothing to do with it - "this" can only be null if you didn't create an object you're calling it on.
>
 you can not call a method via the vtbl is 'this' is null (you can't get the
vtbl).
the original point was ....
someone wanted non-virtual (so possible for 'this' to be null if the object
was not initialised) walter said final which is true (when optimised to
direct calls) so can be called so that the 'this' within the function is
'null' (i.e. on non initialised objects (another way to do lazy creation))
I was pointing out that final and non-virtual are different and final does
not need to imply non-virtual.

Mike Wynn wrote:
>  you can not call a method via the vtbl is 'this' is null (you can't get the
> vtbl).

Nor you can call any non-static member since it's gonna dereference an offset to an object poiinter to acess members... and whoops!

> the original point was ....
> someone wanted non-virtual (so possible for 'this' to be null if the object
> was not initialised)

if you mean Dario?

> walter said final which is true (when optimised to
> direct calls) so can be called so that the 'this' within the function is
> 'null' (i.e. on non initialised objects (another way to do lazy creation))

my head is spinning!

In Sather it is fully normal for a function to ignore implicit this argument, which is null whenever the function is called not on an object, but on a type using a scoping operator. Or it can test it for being nil and take action.

In fact, i tried to compile and tweak an exaple from Matthew Wilson, but it breaks even on the object which gets created... It may be my stupidity, or a bug, since i have an old compiler version here.

> I was pointing out that final and non-virtual are different and final does
> not need to imply non-virtual.

True. Though the virtual access would only happen if you are calling through a base class object or an interface, where it is not considered final yet.

-eye

"Ilya Minkov" <midiclub@8ung.at> ha scritto nel messaggio news:bj0cej$2lbh$1@digitaldaemon.com...
> Mike Wynn wrote:
> >  you can not call a method via the vtbl is 'this' is null (you can't get
the
> > vtbl).
>
> Nor you can call any non-static member since it's gonna dereference an offset to an object poiinter to acess members... and whoops!

I think that's a different story. You can actually _call_ a non-static function member on a null reference to an object, as long as the address of the function is known in advance (i.e. it is not virtual so there is no need to look at the vtable). The function itself is destined to no glory, though, for the reason you said. But IIRC the point to this thread was whether a D function member may check for "this" to be non-null and take appropriate (application-defined) actions otherwise. A problem that arises immediately is that in D you don't even know if a function member will end up as being virtual or not, because this is part of the automatic optimizations made by the compiler. The only way to make sure that a function member will NOT be virtual is to declare it as final in the very same class that introduces it, so that there will be only one implementation, thus no need for a vtable entry.

I hope I've been of some help. As a matter of fact, this thread has gone so far that in my Outlook Express I can't even see the subject any more, because of answer indentation... :)

Ric