Front page | perl.perl5.porters |
Postings from September 2010
mauve--
Thread Next
From:
Rafael Garcia-Suarez
Date:
September 9, 2010 06:22
Subject:
mauve--
Message ID:
AANLkTi=UHJ-1VMdZnh_KUrB=CTuageTErBGR1o728rGY@mail.gmail.com
So I'm catching up with the changes in perl and I find out about this
mauve namespace. I'm rather horrified :)
Some questions.
- if we're going to define new XSUBs, why should they be in
universal.c instead of in an XS module?
It's confusing. People will use mauve::foo() without loading mauve.pm,
except when they will because they'll backport their programs to an
old perl. And "use mauve" looks like a pragma, due to the
lowercaseness of the name. "Mauve" would have been better. (or "Pink")
- and why this XS module should be in the core?
- another reason to dislike cluttering the default namespace. For one
thing, this will need adjustments in $Safe::default_share, for
example. Currently in blead you won't be able to mix mauve and Safe.
And honestly, fiddling with the default share everytime some function
is added to re::, utf8:: or version:: is painful.
- why don't we add new keywords instead? They're faster. They're
overridable. Perl 5 has acquired new keywords since 5.0 already.
- ah, but new keywords can break stuff. What's this fuss about
feature.pm about? feature.pm is for new syntax, not for every kind of
change in perl. The features given, say and state are all keywords
that can't be parsed as functions. You can't backport them as modules
to older perls (unless you use source filters). That's not the case of
reftype() and friends. With reasonable prototypes they can completely
behave as functions. Weak keywords is the way to go.
Thread Next
-
mauve--
by Rafael Garcia-Suarez