On Sun, Dec 02, 2001 at 02:21:38AM -0500, Jeff G wrote:
> 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.
I don't think there'll be any more we want to add.
> 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...)
I don't see what you mean - isn't this what pmc->vtable->type is about?
> 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.
That's just a hack. I think you're expecetd to know that interpreter PMCs
aren't real ones. However, type 0 will soon be used by a PerlUndef class.
> Incidentally, I personally would find something
> like 'new P0,"interpreter"' or 'new P0,"perl_scalar"' clearer than a
> cryptic digit.
Yep. This requires fixing the assembler to know about the enum in vtable.h
Simon
--
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
