[EMAIL PROTECTED] via RT wrote:
On Sun Oct 01 16:22:10 2006, mdiep wrote:
At the OSCON 2006 Hackathon, it was decided that we should separate
vtables from methods and add a new :vtable label for PIR subs to mark
them as vtable functions. This gets rid of the current namespace
pollution caused by vtables and allows us to abandon the leading
underscores for PIR vtable functions.
.sub get_string :vtable
.return("end namespace pollution!")
.end
Just to check, that this is still meant to happen? Anyone feel it should
be put off until the objects/namespaces stuff is sorted out, or shall I
just dive right in?
This is the main thing Chip and I talked about in our last face-to-face
meeting. We came up with 3 basic parameters: whether a method is a
vtable method, whether it has a vtable name distinct from the method
name, and whether it has a method name at all (or is anonymous, i.e.
only a vtable method). The interface I scrawled out over coffee is:
# method name is the same as vtable name
.sub get_string :method :vtable
# accessible as either $obj.stringify() or vtable
.sub stringify :method :vtable('get_string')
# accessible only as vtable
.sub get_string :method :anon :vtable
.sub stringify :method :anon :vtable('get_string')
Which reuses the existing concept of:
# method has an entry in the namespace
.sub stringify :method
# method has no entry in the namespace
.sub stringify :method :anon
(There's not much point in using the 4th option where you specify a name
for the method, make it anonymous, and then specify a separate name for
the vtable entry, but we'll support it for the sake of orthogonality.)
The reasoning for making :vtable additive rather than exclusive with
:method is that it's common to want to add behavior that's both a method
on the object and a vtable entry.
As a side effect of this solution, the leading double underscore goes
away for vtable names. So it's now just 'init' instead of '__init',
'get_bool' instead of '__get_bool', etc. The underscores were just a
hack to alleviate namespace pollution anyway.
Even though "pure" vtable methods aren't stored in the addressable part
of the namespace, we came to the conclusion that they should be attached
to the namespace, because an anonymous class can be associated with a
namespace at runtime, and when it is, it should get not only the methods
of that namespace, but also the overloaded vtable entries.
(I can see an argument of brevity for an alternate solution where the
3rd and 4th options have only :vtable and not :method and :anon:
# accessible only as vtable
.sub get_string :vtable
.sub stringify :vtable('get_string')
but I don't like the fact that this would make :vtable mean different
things in different contexts. Together with :method, :vtable would mean
"also make an entry in the vtable overload list for this namespace", but
without :method it would mean "don't make an entry for this subroutine
in the namespace, and treat this subroutine as a method, and make an
entry in the vtable list". I prefer to keep each of those separated into
their own adverbs, especially since we already have the adverbs.)
Allison
