Now I'll be the first to admit that I'm probably not the most coherent
in the world at (looks at the clock) 1:19 A.M. but I'm sitting here
trying to get something like a PerlInt_Array ready for compilation and
noticing some problems. It's also entirely possible that I'm looking at
this in the wrong fashion, so someone please correct me if I'm wrong.
Currently vtable.h is dynamically constructed from what would appear
to be a union of all possible operators on {int,num,string}. Now, this
is certainly handy (especially after having to cast one type to another,
and making heavy use of said vtable entries), but this will also become
unwieldy quickly. One simple example we have right now is the existence
of operations like PerlNum_logical_or.
It's nice to have the ability to call any vtable method blithely
against any PMC, and in fact the current PMC strings &c do just that.
(Incidentally it would be nice to have some way to identify a value by
other than an if(){}else(){} on its vtable member...) However, as we add
more and more members to this vtable structure, it will become really
unwieldy.
I'm not advocating custom-created vtables for each single class (That
would involve tables to do the mapping of get_integer functionality from
one vtable class to the next, or making sure that get_integer was always
item 1 in a particular vtable or some such...) Instead I'd like to see
each different vtable type (object, if you will) have its own set of
vtable entries.
This would involve (unfortunately) one more level of indirection
(Namely the interpreter looking at the current PMC type, and dispatching
to a new vtable), but it would save a great deal of space within the
vtable design. I'll probably work on this design once I have a clearer
head. Looking back on this, I guess this rant equates to "Make 'new
P0,<n>' switch in vtable #n when used".
Looking at the current tests, apparently the new 'interpreter' PMC
also uses type 0, so the problem would appear to be slightly deeper than
what I've commented on. Incidentally, I personally would find something
like 'new P0,"interpreter"' or 'new P0,"perl_scalar"' clearer than a
cryptic digit. However it would be slightly slower to compile that way.
In any case, please take these ramblings with several grains of salt.
Tomorrow I'll work on the system I suggested and see how far I can get
with this idea.
-Jeff
<[EMAIL PROTECTED]>
