underscores in the core lib
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).
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 [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpVoL9QodN0W.pgp
Description: PGP signature
Re: underscores in the core lib
On 8/6/06, Yuval Kogman [EMAIL PROTECTED] wrote:
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 Iin 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
