Front page | perl.perl5.porters |
Postings from September 2022
Re: module loading built-in
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
September 17, 2022 08:45
Subject:
Re: module loading built-in
Message ID:
84d52872-553e-8905-7c4e-da529b7f23e4@darrenduncan.net
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
regardless?
> # 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