On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote:
: Damian Conway wrote:
: >The relevant suggestion regarding hyphens vs underscores is:
: > "...to allow both characters, but have them mean the same thing."
: >That is, any isolated internal underscore can be replaced with an
: >isolated internal hyphen (and vice versa), without changing the meaning
: >of the identifier.
: I am formally opposed to this idea. I see that making underscores
: and hyphens to be equivalent is akin to having case-insensitive
: identifiers, where "Perl","PERL","perl" mean the same thing. Rather
: what I want is to be everything-sensitive, as AFAIK Perl 6 currently
: is; if something looks different, it is different. -- Darren Duncan
Well, Perl 6 won't be everything-sensitive, since by default it does
string comparisons under some kind of Unicodian Normalization.
But I'm inclined to keep - and _ as unique characters, and just let
the culture evolve over time; I think the end result will be to require
(by convention) official APIs to use hyphens for all normal interfaces;
underscores anywhere in a name will come to mean "this is private,
use at your own risk" regardless of where underscores are used,
much like current meaning of leading underscores. But I don't think it
should be anything tighter than a convention, or we make language
interoperability more difficult (particularly with Perl 5).
As for the horror of people having to memorize lists again or
Risk Using The Wrong Character...I'm afraid I just don't buy it.
The standard parser will likely be pointing out spelling errors and
conjecturing emendations for near misses. Whole-program analysis can
even do this for any method names that look wrongish. The difference
between Acme-X and Acme_X is no worse than the difference between
Damian and Damien, at least in Levenshtein distance.