1) builtin methods are living in a class namespace e.g.
Float."cos" ParrotIO."open" # unimplemented
I'm way out of the loop and may have been dealt with in prior mail, but are we doing real method calls for cos() and suchlike things? That seems... sub-optimal for speed reasons. (Open I can see, that makes sense, though I'm not sure I'd want it for any other file operations, again for speed reasons)
I've been thinking it may be worth pulling out some groups of semi-commonly used functions that should be fast but still PMC-class-specific, and thus not methods, into sub-tables hanging off the vtable. Most of the semi-high-level string functions (basically everything that may be delegated to the charset/encoding layers) would be a candidate for this. Possibly the standard trig functions too.
This'd cost us a single pointer per sub-table per pmc class, and one table of generic functions per sub-table, so it'd not be that expensive, yet still allow classes to override the default functions on a per-class basis without the overhead of full method dispatch.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
