develooper Front page | perl.perl5.porters | Postings from September 2022

Re: module loading built-in

Thread Previous | Thread Next
Darren Duncan
September 17, 2022 08:45
Re: module loading built-in
Message ID:
On 2022-09-17 12:50 a.m., Branislav Zahradník wrote:
>>> Advantage:
>>> - namespace methods will not pollute namespace for other methods
>>> - namespace methods will always be prefixed with *
>> Is this a situation where we want to start having special syntax for particular
>> method calls?
> these are no ordinary methods, these are methods invoked on internal data.
> It's similar to My::Class::->meta->..., but instead of having meta
> method (polluting user's namespace)
> it will signal that this is internal method.

What you're saying here sounds wrong to me.  Its coming across like these 
methods are unique and nothing like them has ever existed in Perl before.

Also the whole idea of "internal data" as distinct from regular data doesn't 
make sense.  In reality there is no such distinction.  I say that every kind of 
data made visible to users of ordinary Perl code is normal data.

Also the existing method of "builtin::foo" already prevents pollution of the 
user's namespace, so why not just use that instead of introducing this new 
syntax?  I feel that the bar for adding this star-syntax needs to be much 
higher, it should be saved for much more valuable use cases where it would be 
used very frequently.

> As far as Perl doesn't distinguish between namespace and instance of
> namespace special syntax
> is needed. Either non-OOP (using builtin) or this prefixed.

While I'm a strong supporter of having stronger typing in Perl, in the meantime 
why is it not good enough for a regular string scalar like `"Module::Foo"` not 
suffice to represent a namespace?

Especially since Perl already does this, as far as I know, which is why you can 
say `$class->foo()` etc.

I would also argue that creating special Perl syntax for namespace literals 
should be done FIRST, and BEFORE considering this star-syntax.

So we currently have literal syntax for integers, floats, and strings, and 
booleans and undef in a way, so lets add a new literal syntax for namespace 
literals, and for that matter it should have its own core data type of course, 
like how int/float/string/bool do now.

If we have an actual distinct type for a namespace, would that mean the 
rationale for the star-syntax goes away, or do you still see its important 

> # per-namespace overload
> Makes no sense for `'load_module` but may for others, eg (showing
> intention, no real implementation):

I believe the core implementation of builtin::load_module() etc should NOT be 
overloadable, and the builtin version has only one behavior.

If we want multiple fundamental behaviors, that's provided by having either 
multiple distinctly named builtin::foo() and/or some of them take extra 
arguments to determine it.

Beyond that, anyone is free to define other alternate loading behaviors in Perl 
as wrappers over the builtins, rather than overloads.

> I already wrote pre-rfc about namespace literals, see "Pre-RFC:
> namespace literal as first class citizen" (sent 2022-06-30)

Glad to hear it.  I have yet to read the details of your proposal but in 
principle would support that much more than the star-call workaround for their 
absense or builtin:: option.

-- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About