I'm working on objects this morning--I need 'em, so they've become
unavoidable. (boo!) So, anyway, here are a few design decision things.

*) While we've facilities for a method cache, I'm ducking that for
now. I expect performance to suck rocks until that's undone, but to
do it right requires notifications.

*) While I *really* want to hide the details for now, under the hood
we're going with a flat namespace system, with elements of names
separated by NUL characters. If you're creating multilevel names
(foo::bar::baz) then replace the separators with NULs. ASSEMBLY
PROGRAMS ARE ALREADY ASSUMED TO DO THIS!

*) The name of the fallback method, which is called if no matching
method is found, is referenced as the property "__FALLBACK__" on the
class PMC. All languages generating parrot code should set this
property appropriately. (Yes, I want to dodge the whole "what the
heck is AUTOLOAD called in *this* language problem. Fooey. It's
metadata, so we'll treat it as such)

*) We may or may not go with a split function/data namespace scheme.
Probably not, and if we don't functions/methods will have a prefix
character of some sort. Parrot will affix the appropriate prefix when
it has to internally, so don't worry about this quite yet.

*) I've made the Parrot_base_vtable array movable again, as it needs
to be resized. This is a temporary hack, since there are horrible
threading issues here. (Not to mention the fact that this table is
global and really ought not be, or we need a per-interpreter-family
version that's actually used)
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk