Front page | perl.perl5.porters |
Postings from September 2022
Re: module loading built-in
From: Branislav Zahradník
September 17, 2022 20:54
Re: module loading built-in
Message ID: CAB=rbOn_wEjCuRr62E==bdCsEq1AZGsbn-AQqCYqJZj6Gh4OGg@mail.gmail.com
> > 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.
I will use example from raku and its Grammar, problem I ran into
whenwriting SQL parser:
- you cannot create token CREATE, because it is used by language
- you cannot create token before, because class method before is used
by language to handle lookaround
With star syntax it will be clearly visible
- this method is user method (and part its intended interface)
- this method is a hook defined by language to augment default behaviour
That's what I meant mentioning "pollute user's namespace" and "internal data"
> 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?
Perl already supports trailing ::, even with special warning, so that
is good candidate
for namespace literal (more details in mentioned pre-rfc), eg:
> Especially since Perl already does this, as far as I know, which is why you can
> say `$class->foo()` etc.
yes, and that's reason why I suggested star syntax, to distinguish
static methods called on class
and methods called on namespace itself
> I would also argue that creating special Perl syntax for namespace literals
> should be done FIRST, and BEFORE considering this star-syntax.
Agree, though these works are independent
> 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
I think star-syntax (or other variant, I used star only because it
looks nice on my monitor)
is important regardless of implementation namespace literal - this
methods are not parts
of given namespace API.
> 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.
builtin methods are pretty similar to operators
builtin methods should be overloadable (though load_module will not be
because it will be executed before any overload will be defined)