Front page | perl.perl5.porters |
Postings from September 2022
> > 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: Module::Foo:: > 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 > regardless? 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) Best regards, BranoThread Previous | Thread Next