Okay, I think we completely misunderstood each other. Honestly, most of what I
said was a reply to Allison's proposal.
On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 18 April 2007 13:34, Alek Storm wrote:
> Vtable methods defined in C are visible from C.
Of course, otherwise nothing would be able to call them.
It was kind of a "duh" statement, but I was making the point that vtable
methods in PIR should be visible by default.
> Therefore, it makes
> sense that vtable methods defined in PIR are visible from PIR, at
> least by default.
That makes no sense to me. Are you saying that vtable methods defined in a
specific language should be visible to that language by default?
I'm not entirely sure what you mean - I didn't mention languages. I meant that
vtable methods are simply normal methods in a class, which can be easily hidden
with the :anon flag. This is exactly the way it works now - I didn't propose
we change anything besides making :vtable imply :method.
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? I haven't said anything remotely like
this.
That's precisely what vtable methods protect against! That's why they're in
vtables. That's why they're *not* visible as methods to PIR code.
I don't really see where you're coming from here. Vtable methods are callable
directly from C, so there's obviously no problem there. Vtable methods in PIR
are just overriding their C implementations, so it makes sense that they're
callable directly as well. Also, they are easily hidden with the :anon flag.
None of this is any different than what is already implemented.
> Making :vtable imply :anon might be unintuitive to
> users. Besides that, there's still the problem of :method meaning two
> different things with that implementation. Basically, in a non-vtable
> sub, there is the :anon flag to detach it from the namespace, but in a
> vtable sub, it's detached by default, and the :method flag attaches it
> to the namespace. Reversal bad. Continuity good.
I can't honestly think of a case where you want :vtable AND :method on a
vtable method, with the caveat that right now you *must* do that
because :vtable doesn't cause Parrot to include the invocant in the proper
register on calls.
I was talking about Allison's recommendation. If you read that, what I said
will make sense.
Sorry for the miscommunication :)
--
Alek Storm
