On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote: > From: Leopold Toetsch <[EMAIL PROTECTED]> > Date: Wed, 12 Jul 2006 21:15:44 +0200 > > On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote: > > The perl6 compiler has a custom string type, currently called > > "Perl6Str". What's the canonically correct mechanism for creating > > an object of that type? > > > > $P0 = new 'Perl6Str' > > $P0 = new .Perl6Str > > $P0 = new [ 'Perl6Str' ] > > 2) only works, *if* the lib, which defines that type is already > loaded (via :immediate/loadlib or .loadlib), because it's > translated to new_p_ic, i.e. the type name is converted to > a type number at compile time, which speeds up run time > object creation. > > So the type is bound to a number in the .pbc? Isn't this dangerous for > types that are not built in? Couldn't this number mean something > different if libraries happen to get loaded in a different order?
IIUC, the type is bound to a number in the .pbc only for the second form (.Perl6Str). And yes, it is dangerous for the non-built-in types, which is why I think the note in DEPRECATED.pod is likewise dangerous: =item Class name IDs ... will require a dot in front $P0 = new Integer => $P0 = new .Integer AFAICT, the only safe form for the non-builtin types is to use a string, a key, or the separate find_type lookup...which is what prompted my original question in this thread about which form is canonically (and operationally) correct. Pm