For those of you not watching the Parrot subversion log (and why not?):
* Opcodes {get,make}*namespace and {get,set}*global again accept arrays of
names in place of constant keys ...
* ... obviating the corresponding Namespace PMC methods, which are now gone.
* Time to 'make realclean'.
(And of course I repeat a gentle reminder that the old find_global and
store_global opcodes will eventually [eventually!] go away, so convert
to the {get,make}*namespace and {get,set}*global opcodes instead.)
In the process of the above change, these more fundamental low-level changes
were needed (or at least helpful):
* Keys passed to opcodes as plain values -- i.e. as namespace or class
identifier rather than for their classic indexing purpose -- are now
encoded in opcodes differently, as "_pc" ("inconst PMC") rather than
the historical and ambiguous "_kc" ("inconst KEY").
* Therefore if you can get a Key PMC into a PMC register, many of the
key-accepting opcodes will accept the key via the register. However,
some won't; see "Note" below.
* Op parameters "in PMC" used to be silently treated as "invar PMC" (i.e.
no PMC constants allowed). This is no longer true. However, most
opcodes still behave just like before, thanks to a massive search-and-
replace of "in PMC" with "invar PMC".
Note on an insteresting design issue: The new 'subclass' opcode variants
demonstrates the inherent ambiguity between class names and class PMCs;
merely being a PMC or not isn't enough to distinguish the intent of
specifying class vs. class name. (Keys are PMCs.) This should be resolved
in a general way for all class-accepting opcodes.
--
Chip Salzenberg <[EMAIL PROTECTED]>
