Alek Storm wrote:
This seems perfectly fine to me. The only change I think should be made is that :vtable automatically sets :method to true. Using :anon to exclude it from the namespace is what you originally proposed, so I'm curious why you've changed your mind.
Because I realized that under that system, you could never use :vtable by itself (there's no such thing as a vtable without a PMC), and because the most common case (only overriding the vtable entry and not modifying the class namespace) required 3 modifiers on the sub. This way the 2 most common cases each only need one modifier (:method or :vtable).
Making :method mean one thing when used with :vtable, and something completely different without, seems like a really bad idea to me, and is confusing to the user. The user will also be confused because adding :vtable removes it from the namespace, which they didn't explicitly ask it to do. What is :anon good for if we use a completely different system for :vtable?
The whole point of the original change was to keep vtable overrides from polluting the namespace of the class. vtables are Parrot's way of interfacing with PMCs at a low-level, and not every language will want all the vtable behavior exposed. When they do, we give them the option, but we don't expect most classes written in PIR to expose the vtable entries as methods.
.sub get_string :vtable :anon # unspecified
Just no effect, since :vtable already implies no entry in the namespace.
.sub get_string :vtable :method :anon # now we're in trouble
Just like ":method :anon", but also stores it as a vtable entry.
The same thing, with what I've proposed: .sub get_string # normal sub, attached to a namespace but not a method .sub get_string :method # a full method, attached to a namespace .sub get_string :vtable # a method that also overrides the vtable .sub get_string :vtable :method # same as before .sub get_string :vtable :anon # same, but not attached to the namespace (note that the user has actually specified this, so they expect it to happen) .sub get_string :vtable :method :anon # same as before
This works too, but doesn't optimize for the most common case. Allison
