underscores in the core lib
Yuval Kogman
Audrey mentioned that Perl 6 is trying to avoid underscores in the
core library.
It came up when I asked why "valid" isn't called "value_id" because
if ( $user_input.valid ) { } reads fairly confusingly.
So, a few questions:
1. what is the "official" naming style for the Pelr 6 standard
library (not just functions, but methods for core objects, the MOP,
the compiler toolchain, the truely absolutely core modules, etc).
2. What is bad about underscores? From what I know most people tend
to think that $object.do_that_action is the clearest way of naming
methods, and the technical reasons to avoid these (long symbol
names, lots of typing) are no longer really valid nowadays (with
editor autocompletion, etc).
3. why are some core methods named ALLCAPS (BUILD, BUILDALL)? Or
perhaps more accurately, which types of other methods should also be
in ALLCAPS? and is ALL_CAPS also OK? Or is that for constants?
4. If really make a departure from short names, will things that
sort of model POSIX (IO, etc) have short synonyms? or will these be
named in their short form?
A request to the thread participants - please try and form your
arguments on a "good for everyone" level, not just what your
personal preferences are. I don't think that anyone's opinion
matters except @Larry's, and you're not going to change their minds
if you simply present stylistic argumetns.
-----------
My own spiel:
I would like to see a slight departure from the C-style naming
convention (which I must admit i really really dislike - remembering
std c library names when you don't use them all the time is tricky,
and consequentially so is looking them up in the docs).
I would very much like Perl 6 to be a language that's easy to read
as you go along, where consulting the documentation isn't always
necessary to understand what's going on.
A unix head may read:
$file.chown( $user );
wait( $pid );
easily, but anyone with sufficient understanding of the program's
behavior can understand what
$file.change_owner( $user );
wait_for_process( $process_id );
is without being aware of the conventions.
Of course, this has downsides too- it defies an existing convention,
(These are standins for old UNIX functions which "everyone already
knows").
However, we will also have new APIs, like the OO meta model:
my @attrs = $meta.attributes; # shallow
my @deep = $meta.compute_all_attributes; # deep, also from superclasses
Than
my @attrs = $meta.attrs;
my @deep = $meta.compattrs;
--
Yuval Kogman <nothi...@woobling.org>
http://nothingmuch.woobling.org 0xEBD27418
Ashley Winters
> Hi,
>
> Audrey mentioned that Perl 6 is trying to avoid underscores in the
> core library.
>
> It came up when I asked why "valid" isn't called "value_id" because
> if ( $user_input.valid ) { } reads fairly confusingly.
>
> So, a few questions:
>
> 1. what is the "official" naming style for the Pelr 6 standard
> library (not just functions, but methods for core objects, the MOP,
> the compiler toolchain, the truely absolutely core modules, etc).
>
> 2. What is bad about underscores? From what I know most people tend
> to think that $object.do_that_action is the clearest way of naming
> methods, and the technical reasons to avoid these (long symbol
> names, lots of typing) are no longer really valid nowadays (with
> editor autocompletion, etc).
Nothing is wrong with underscores. In fact, under_scores and
camelCase/StudlyCaps should be encouraged I<in user code>. When you
see function_name() or functionName() or _functionname(), it should be
obvious to any Perl programmer that it's *not* a standard Perl
function -- it's a user/module function. When you see SCARYCAPS, you
should expect out-of-band implicit (action-at-a-distance) behaviour
from whatever code it in it.
Think of underscores and caps as a form of twigil. $scalar, @array,
%hash, &sub, &_internal, &userFunction, &user_function,
&RefugeeWindowsProgrammer, &Let_There_Be_Poetry, &MAGIC,
&UNAUTHORIZED_USER_MAGIC.
And, just like $scalars can hold arrays, &somesub could be a standard
function or a user function (or a standard function which a user
reimplemented -- you never know).
- Ashley Winters
Eric
Unless you already know what it means you don't have any clue that
its not actualy the word valid instead of val_id. I don't know of any
other problems like this, but at very least that should be changed.
Don't we still try and follow the rule of least surprise!! ? I was
realy surprised to find out that valid was value_id, especialy since
the last reference I saw to it was along side defined, undefined, etc,
so I assumed it was related to that.
/me scratches his noggin.
I don't have any other arguments for _, but it would be interesting to
hear the reasoning agianst it. The builtin versus userdefined is
getting realy blury in p6 anyway so it seems weird to use this as a
way to define it, after all it's not like all user functions WILL have
_ in there name.
--
--
__________
Eric Hodges
Juerd
> I think .valid is an excellent argument for underscores all by itself.
I think it's an argument for reconsidering the name of that method.
"valueid" is only 2 characters more.
I'm personally against non-prefix underscores in any core identifier.
I agree that "valid" to mean "value ID" is a bad idea, though. It's
extremely ambiguous.
> I don't have any other arguments for _, but it would be interesting to
> hear the reasoning agianst it.
Forbidden underscore encourages the designers to think much harder about
the best name, because it automatically rules out things like "valid" if
you stick to sanity. It may be so that "value ID" itself is a bad name.
Also, having_underscores leads_to longer_names, in my experience. Longer
names are great for my own code, but I want core stuff to be consise and
short.
> On 8/6/06, Ashley Winters <ashley....@gmail.com> wrote:
> >On 8/6/06, Yuval Kogman <nothi...@woobling.org> wrote:
Please do not answer above the quote.
Regards,
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Larry Wall
: Eric skribis 2006-08-10 10:22 (-0600):
: > I think .valid is an excellent argument for underscores all by itself.
:
: I think it's an argument for reconsidering the name of that method.
: "valueid" is only 2 characters more.
Okay, I'll just hop in my DeLorean and fix .valid yesterday. (Will probably
leave some SKID marks though...)
: I'm personally against non-prefix underscores in any core identifier.
Yes, it's a design smell. The point of core is to huffman code common
things, so something in core with _ should normally either be shorter
or out of the core.
Larry
Luke Palmer
> Yes, it's a design smell. The point of core is to huffman code common
> things, so something in core with _ should normally either be shorter
> or out of the core.
I don't think I agree. I've been programming in Ruby, and I
appreciate all the nice convenient methods it gives me. I fear that
if underscores are not allowed in the core, then we will have to omit
methods like Ruby's 'protected_methods' or 'instance_eval' in favor of
some more superfluous syntax.
I think that standard functions ought not to have underscores *most of
the time*, because their presence indicates something that could be
better named or is miscategorized. However, for methods, especially
"advanced" or introspective methods, I think longer names that
describe the action are better than short ones that only describe the
action if you understand the pun. Huffman coding does not imply that
*everything* is short.
Luke
Audrey Tang
在 2006/8/11 下午 2:35 時，Luke Palmer 寫到：
> I think that standard functions ought not to have underscores *most of
> the time*, because their presence indicates something that could be
> better named or is miscategorized. However, for methods, especially
> "advanced" or introspective methods, I think longer names that
> describe the action are better than short ones that only describe the
> action if you understand the pun. Huffman coding does not imply that
> *everything* is short.
.SKID and the like are methods of Object, and as such should be
considered
part of the standard functions, as they are available to all terms.
Methods for the other implicit-coerced-to types (Bit/Int/Num/Str/
List) share
this concern; because all terms may be coerced implicitly into them,
their
methods also have unbounded visibility.
For other built-in types, I think underscore names are just fine.
For example,
metaclass methods such as "Class.has_method" should indeed remain as
such. :)
Thanks,
Audrey
Larry Wall
: For other built-in types, I think underscore names are just fine. For example,
: metaclass methods such as "Class.has_method" should indeed remain as such. :)
That's fine--I don't think of anything behind the META curtain as "core",
at least not in the sense that I was meaning it earlier.
Larry
Charles Bailey
> things, so something in core with _ should normally either be shorter
> or out of the core.
Would it be adequate to say "think hard about keeping core names
concise, but prefer clarity to conciseness when they're mutually
exclusive"? Have I just said the same thing you did above?
If I need to use
core_function_for_enabling_extremely_convenient_unified_process five
hundred times a day, how hard is it for me to alias it to coffeecup?
(Of course, if everyone thinks coffeecup is the obvious choice, then
that's a better candidate for the core name, but if only a subset
think coffeecup is valid, then they might choose an alternate Huffman
code.)
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu