develooper Front page | perl.perl5.porters | Postings from October 2013

Re: Features and keywords versus namespaces and functions

Thread Previous | Thread Next
Father Chrysostomos
October 23, 2013 01:03
Re: Features and keywords versus namespaces and functions
Message ID:
This is a response to the entire thread, in light of ticket #119189.

Yves Orton wrote:
> I would like to start a dialog about when it is appropriate to extend
> Perl via features and keywords and when it is appropriate to extend
> Perl via namespaces and functions.
> As far as I understand the feature/keyword approach is required when
> the change involves modifying how Perl code is parsed. For example
> adding a new infix operator has the potential of breaking code that
> uses the same token as a function name or worse cause it to be
> interpreted in entirely new ways without breaking.
> Namespaces on the other hand exist to work around the problem of
> function name collisions. They are the standard way to add library
> code to an application in Perl and virtually all other modern
> languages.
> I have seen and been involved in conversations where people have
> argued that new *functions* be added to the language as keywords and
> enabled as features instead of as functions in a built in namespace. I
> believe that this is a mistake and would like to begin a debate which
> I hope will lead to a new policy on this matter.

Namespaces make sense if the name of the space is inteended to be part
of the name of the function.  utf8'decode is one such example.

If we were to put, say, reftype in the ref:: namespace, then
ref::reftype would be redundant.  It would make more sense to call it

If we want any functions to be exportable, then the basenames must not
clash, which defeats the whole purpose of having namespaces to begin
with.  That is especially true if we want certain keywords to be
available by default under ‘use v5.42’.

To me, it makes things conceptually simpler if any keyword enabled (or
exported) by ‘use feature’ or ‘use v5.42’ is also available as

> I would really like to get this sorted out. I have a number of patches
> pending that I believe are useful and worthy additions to perl core
> which IMO are best added as functions in specialized namespaces and I
> would like to get the policy debate on this subject done independently
> of the merit debate that any such patch requires. IOW, I do not want
> to confuse a given contribution with this debate, I want this debate
> to be abstract.

I am going to ignore your last sentence and propose a compromise spe-
cific to your patches.

If you want them to be available as scalar::reftype, scalar::blessed
and scalar::weaken, and if others want them available under ‘use
v5.42’ (I believe David Golden does), then let’s do both.

If they end up in CORE:: as well, I don’t see that as a problem.
\&scalar::reftype == \&CORE::reftype could be true.

(My only objection (and I’m changing subject a bit), is that
mauve::blessed does not return a boolean, so we still need
defined(blessed(...)) to detect an object.  (Do you mind chang-
ing that?))

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