On Apr 18, 2007, at 3:48 PM, chromatic 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.
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?
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?
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.
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.
Fixing that makes these problems all go away.
-- c
And if vtables are anonymous by default, it'll make it possible to have
a vtable and a method, with the same name. I think it's more likely to
be a good thing than a bad thing, but I imagine it will at some point
cause a problem for someone, other than confusion.
No one ever said the logic of a virtual machine intending to support
all dynamic languages would be simple.
