Re: underscores in the core lib
On 8/10/06, Larry Wall [EMAIL PROTECTED] wrote: 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. 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
Re: underscores in the core lib
On 8/10/06, Larry Wall [EMAIL PROTECTED] wrote: 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
Re: underscores in the core lib
在 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 PGP.sig Description: This is a digitally signed message part
Re: underscores in the core lib
On Fri, Aug 11, 2006 at 11:28:08PM +0800, Audrey Tang wrote: : 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
Re: underscores in the core lib
I think .valid is an excellent argument for underscores all by itself.
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.
On 8/6/06, Ashley Winters [EMAIL PROTECTED] wrote:
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
--
--
__
Eric Hodges
Re: underscores in the core lib
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. 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 [EMAIL PROTECTED] wrote: On 8/6/06, Yuval Kogman [EMAIL PROTECTED] 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
Re: underscores in the core lib
On Thu, Aug 10, 2006 at 07:02:13PM +0200, Juerd wrote: : 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
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
