On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 18 April 2007 14:15, Alek Storm wrote:
> > If that's true, then users have to *know* the implementation details of
> > vtable methods. Is it in C code or is it in PIR code?
>
> I have no idea why you're saying this. Why does making vtable methods
> visible expose their implementation details?
Vtable methods written in C are not visible to PIR code.
True, but there is an increasing number of PCCMETHODs being written
that are just wrappers around a vtable method. Again, having the
vtable override visible is *optional*. Just like writing a PCCMETHOD
wrapper is optional.
See the code example I posted.
> I haven't said anything remotely like this.
If vtable methods written in PIR are visible to PIR code, I can draw no
other conclusion.
If I want to use a PMC and call a vtable method directly from PIR, I can do
that if and only if that method is a method defined in PIR. I cannot do
that if the method is a method defined in C.
Thus for my code to work robustly, I have to know about the internals of the
method and hope that it does not change.
I see what you were saying now - the user has to know whether a vtable
method was written in PIR or C to call it directly. There are two
choices involved here. The first is the choice of the user, who, by
calling it directly, has chosen to code for that specific PMC. Nobody
is forcing the user to do this; they can just as easily use some form
of indirection, just like before. The second is that the author has
the choice of providing a visible vtable method to the user, or not.
This is just like writing a wrapper around the vtable method in C or
PIR, only more convenient. No semantics are changed.
Again, the only part of :method that :vtable needs to imply is the part that
sets the invocant in the proper register and makes 'self' available within
the body of the method.
So, that still means :method can mean two different things, depending
on whether :vtable is present or not. That's still bad.
--
Alek Storm
