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
