Am 24.08.2011 11:33, schrieb Carl Mäsak:
Damian (>>>), Moritz (>>), Smylers (>):
... why hidden_from_backtrace instead of hidden-from-backtrace?
... low-level things are spelled with underscores, while we reserve
the minus character for user-space code.
So the idea is that if Perl 6 has an identifier zapeth_clunk itself that
leaves zapeth-clunk free to be used by developers to mean something
else?
Not much of a problem in Perl 6 in the first place; built-ins from the
setting are considered to be lexical declarations from a block outside
of the mainline program code, and any declarations made by the
developer will just shadow these.
No, my understanding is that the naming convention is there to
separate stuff API stuff from internals stuff:
dashes
this is part of the Perl 6 API -- feel free to call it
underscores
this is an internal function -- unless you're doing something
internal yourself, you shouldn't call it
To me, it has a nice visual mnemonic, since underscores themselves are
more "low-level".
That's how I understood it too, but wasn't able to phrase it so nicely.
Of course, it remains to be seen whether this convention is (a)
useful, (b) correctly guessing the boundaries between API and
low-level, or even (c) consistently applied within the spec.
(c) is false, I'm quite sure. I'm all for cleaning it up, once we agree
on a naming scheme
Damian (>>>), Patrick (>>), Smylers (>):
I'd like there to be a more consistent approach than that
+1 to consistency.
Could we have underscores and hyphens mean the same thing? That is, Perl
6 always interprets illo-figut and illo_figut as being the same
identifier (both for its own identifiers and those minted in programs),
with programmers able to use either separator on a whim?
That would seem to be the most human-friendly approach.
It's not machine friendly. It means you can't easily dispatch methods by
looking them up in hash, you first have to name-mangle. And consider how
often you call methods in Perl 6 (like, all the time), that wouldn't be
nice at all.
Maybe, but in my humble opinion that wouldn't promote consistency in
user code. Also, the name mangling needed to do this would waterbed up
*somewhere* and likely cause new, interesting kinds of pain.
Like interoperation with other languages. What if you call methods from
a language that doesn't have this name mangling rule (like, all of
them)? Suddenly you must be careful where you didn't have to be careful
before. So a best practice would evolve that you always be careful in
the first place, and the whole idea is being frowned upon.
Let's take a shortcut, frown upon the idea right now, and don't spec it :-)
Cheers,
Moritz
