Re: [perl #112810] package confuses newly declared class withbuildin

On Tue, 8 May 2012, jnthn@jnthn.net via RT wrote:

> On Mon May 07 16:21:12 2012, gfldex wrote:
>> package A { class Str {}; our sub foo() { return Str.new } }
>>
>>> This type cannot box a native string
>
> Run it with -e and you see it's actually a compile-time error too:
>
> ===SORRY!===
> This type cannot box a native string
>
> Looking in to what happens, things go wrong like this.
>
> * You change the meaning of Str

I do not agree here. S10 says: "Likewise every typename has an associated 
package namespace, even if unused.", as I understand it I therefore do not 
change the bahaviour of CORE::Str but add GLOBAL::A::Str . When I call 
A::foo I expect to get a A::Str that does nothing and should not interfere 
with CORE::Str . What is the point in having namespaces if the compiler 
ignores it?

> * The compiler now wants to create a string constant (as part of
> installing &foo in the package, I think)

The question is what Str it should use.

> * It looks up the Str type
> * Your Str type doesn't actually work like a replacement for CORE::Str
> should, so that fails

Im not sure if I actually wanted to overwrite CORE::Str, probably not. 
(Warning, rethorical question incomming!) Where can I find a complete list 
of built-ins so I can keep track of what names I should not use in my 
user-defined namespace?

Quite frankly, that list is fairly long already and you can't really 
expect new users (read: all those perl5 folk we want to convert) to keep 
track of it.

> So, this is working as designed. Generally, Perl 6 does not draw a
> distinction between built-ins and user-space things; it goes against the
> goal of language extensibility.

Fair enough, overwriting builtins may or may not be a good idea. However, 
the error message does not indicate what the problem is. The first thing I 
thought after reading it was: "What type and what native string? I never 
did any native string!".

A warning that I define a type in my very own namespace, that is then 
going to be used by the compiler instead of a built-in might help a lot. 
Don't get me wrong. Extensebility is great to have. From the perspective 
of a language implementator it makes perfectly sense. From a #perl6user 
perspective it's quite confusing.

I can't really put my finger on the spot but there is something wrong 
here. :-|

have a nice day

• Re: [perl #112810] package confuses newly declared class withbuildin by Wenzel Peppmeyer
• [perl #112810] package confuses newly declared class with buildin by Wenzel Peppmeyer