develooper Front page | perl.perl5.porters | Postings from September 2010


Thread Next
Rafael Garcia-Suarez
September 9, 2010 06:22
Message ID:
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,
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 about? 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About