John Siracusa wrote:
Forgive me if this is a question the reveals how poorly I've been
following Perl 6 development, but what's the deal with some methods
using hyphen-separated words (e.g., day-of-week) while others use
"normal" Perl method names (e.g., set_second)?
There are 2 answers to that question:
1. Unlike with Perl 5, Perl 6 supports the use of hyphens in bareword
identifiers, except as the first character. In principle, I think this is very
welcome, as hyphens are just as reasonable for separating words as underscores,
and several other languages support this, and in XML at least it is standard
practice. For that matter, Perl 6 also supports single-quotes in bareword
identifiers, so you can have routines like isn't() or can't(); I don't like that
so much as I prefer not to have characters used for quoted string delimiters in
the middle of a bareword string, but I can understand why it was done. And so,
if the language supports it and it is reasonable, why not use it?
2. I do think that any particular module should be internally consistent in its
naming scheme, so Temporal should use all-underscores or all-hyphens, but not
mix and match, unless there is a conceptual distinction between things named
with the different styles that are worth highlighting by using different styles;
barring that, such an inconsistency in Temporal may be something that should be
fixed.
-- Darren Duncan
P.S. My Muldis D language also has the feature of Perl 6 about supporting both
underscore and hyphen separated bareword identifiers, though I don't support the
single quotes. While users are free to use what style they want, for all the
built-in stuff I have adopted the following convention: For all normal
identifiers like the names of system-defined routines or variables or parameters
or attributes etc, I use underscore separation. (Type names are typically
camel-case like in Perl.) For language keywords or special operator syntaxes in
the concrete language grammars, I use hyphen separators when said keywords have
multiple words, rather than either underscores or whitespace. I find that this
distinction is very effective at making different things look different, and for
the keywords or special syntaxes, hyphens actually look better than either
underscores or spaces.
