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
