# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #40058]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40058 >
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.
CURRENT STATE OF PLAY
There are currently five distinct ways to identify a class, some or all of
which are used by various opcodes:
(1) Class PMC itself (in P reg)
(2) INTVAL type number (I reg or integer constant)
(3) STRING type name (S reg or string constant)
(4) String PMC type name (String PMC in P reg or PMC constant)
(5) Key PMC type name (Key PMC in P reg[*] or PMC constant)
[*] The P reg version of this is new in my latest changes.
It's not used widely (if at all), and only works for
selected opcodes.
KNOWN FUTURE DEVELOPMENTS
It's already decided that we're moving class PMCs into the normal namespace
tree. This change will eliminate many uses of the class-lookup opcodes, but
not all: There's a two-level search will still be required, where the
universal ['parrot'] HLL provides the fallback for class names not defined
locally -- e.g. C<find_type ['Integer']> could return ['yourHLL';'Integer']
if you've defined that, or else ['parrot';'Integer'] if you haven't.
SUGGESTIONS
I. Opcode cleanup
It seems to me that we should carefully distinguish two types of opcodes:
(a) opcodes that use class PMCs or numbers
(b) opcodes that look up class PMCs by name, and return a PMC or a number
Type A opcodes would use lookup methods 1 and 2.
PMC parameters would always be class PMCs.
Type B opcodes would use lookup methods 3, 4, and 5.
PMC parameters would always be names.
II. Eliminate simple string names for classes, using Keys exclusively
There's little reason IMO to continue to support simple strings for class
names; it multiplies opcodes for the special case of simple class names.
Always using keys would serve as well.
--
Chip Salzenberg <[EMAIL PROTECTED]>
