Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, 2010-04-12 at 11:23 -0700, Larry Wall wrote: > 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. Ah yes, I forgot about this feature. Consider my argument for choosing only one separator throughout the standard setting Way Less Adamant -- though I still think it's a good idea. -'f
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, Apr 12, 2010 at 2:23 PM, Larry Wall wrote: > On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote: > : > : 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 > > ... > 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. > Larry, I'm curious what you think of this example: A web page of Perl 6 documentation suggests that you should call time-local. Unfortunately, in the font that my browser uses, the height of that single stroke is ambiguous. Of course, we could have no sympathy and just say, "get a better font," but this problem will likely creep up over and over, would it not? I agree with you that this doesn't really help the person writing code from scratch, but that's not the same as a developer who is trying to interact with potentially dozens of libraries with various sources of documentation from comments to Web pages. I'd suggest the following in decreasing order of urgency: - Choose a single character (hyphen or underscore) to use in standard library code to separate the component words of an identifier (remember that underscore is only special in C-like code because it's standing in for space). - Never use dash versus underscore notationally (e.g. a-b indicates that the identifier is to be used one way vs a_b indicates otherwise) - Allow only one such character in any given identifier That last item rolls into a whole rant of mine against ambiguity in identifiers. Most often this stems from Unicode that puts the programmer in the position of having to have good enough font support to tell ambiguous names apart (and in cases like "Αpple" or "Рerl" or "Ρerl", you're just doomed regardless), but dashes and underscores are a good example of the same problem cropping up elsewhere. On the more general point, I really feel that no language should ever allow identifiers to mix Unicode blocks without strong reason. Specifically: - Underscore (or dash or whatever your notational separator is) should be the only exceptional character allowed in all identifiers - Identifiers should never include c̈ombining m̅arks - Upon scanning the first alpha character in an identifier, no further alpha characters should be allowed except as they come from the same code block or related supplemental block ("related" might be expanded to include first-class blocks in some cases to allow for combinations like Kanji (Chinese in Unicode) + Hirigana, etc.) - Upon scanning the first numeric character in an identifier, no further numeric characters should be allowed except as they come from the same code block (again, there might be some wiggle in some exceptional cases, but the goal is to avoid counting in more than one system at a time). Should all of these be hard errors? Perhaps not, but certainly they should at least yield warnings by default. PS: While I never finished the implementation of Sand, its simplistic guide to Unicode identifiers might be useful in illuminating what I'm describing above: http://www.ajs.com/ajswiki/Sand:_Syntax_and_Structure#Identifiers -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
Re: underscores vs hyphens (was Re: A new era for Temporal)
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. Larry
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey wrote: > Darren Duncan wrote: >> >> See http://perlcabal.org/syn/S02.html#Names for your answers. > > Thanks for the link but nowhere in it does it state tha Perl 6 names are > case sensitive. The best the do is this, which implies it is but doesn't > state it. > > "Other all-caps names are semi-reserved. We may add more of them in the > future, so you can protect yourself from future collisions by using mixed > case on your top-level packages. (We promise not to break any existing > top-level CPAN package, of course. Except maybe ACME, and then only for > coyotes.)" > > So, I'll ask again: Where in the official documentation does it state that > Perl 6 names are case sensitive? I think it's more important to ask where it says that they aren't. 1) Perl 5 is case sensitive, and the original Apocalypses ran on the basis of 'if it's not mentioned it's the same as Perl 5' 2) The spec assigns no meaning to identifier characters, it just allows you to use a certain set of them. They mean nothing to the language, therefore it has no concept of case to be insensitive about 3) Most popular programming languages are also case-sensitive Maybe it should be explicitly mentioned somewhere, but I think it's a reasonable default assumption. Programmers know that case-insensitivity is a special form of string comparison which involves lots of extra work, so tend to assume (at least in my experience) that it's not going to happen unless they actually ask for it.
Re: underscores vs hyphens (was Re: A new era for Temporal)
Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive. The best the do is this, which implies it is but doesn't state it. "Other all-caps names are semi-reserved. We may add more of them in the future, so you can protect yourself from future collisions by using mixed case on your top-level packages. (We promise not to break any existing top-level CPAN package, of course. Except maybe ACME, and then only for coyotes.)" So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. Eliminate software piracy: use only FLOSS.
Re: underscores vs hyphens (was Re: A new era for Temporal)
Peter Scott wrote: > Am I the only one who sees a hyphen and thinks "binary minus"? Just > because the parser can disambiguate this use of it doesn't mean the > reader's brain can do so as easily. It's all a matter of practice. Since variables begin with sigils, and you should put whitespace around infix operators anyway, it's not really hard. Have you tried looking at actual Perl 6 code that uses hyphens? I have, and I didn't find it hard. > (I assume we're talking about the same character, 0x2D, and not something > from further afield in the Unicode tables, right?) Yes. > Also, what happens when code gets run through mailers or other programs > that think a hyphen is an acceptable place to break a line? Does the > code still work after copy and paste with that newline inserted? The existence of broken tools shouldn't stop progress -- rather the progress should encourage us to fix broken tools (or replace them with better ones). Cheers, Moritz
Re: underscores vs hyphens (was Re: A new era for Temporal)
Am I the only one who sees a hyphen and thinks "binary minus"? Just because the parser can disambiguate this use of it doesn't mean the reader's brain can do so as easily. (I assume we're talking about the same character, 0x2D, and not something from further afield in the Unicode tables, right?) Also, what happens when code gets run through mailers or other programs that think a hyphen is an acceptable place to break a line? Does the code still work after copy and paste with that newline inserted? -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/ http://www.informit.com/store/product.aspx?isbn=0137001274 http://www.oreillyschool.com/courses/perl1/
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a "higher precedence" word-separator than the space (or than its intra-identifier stand-in: the underscore). More is better. It was better to have upper as well as lower case letters in variables. It is better to have - as well as _ The more specialised use of upper case letters, such as SYSTEM identifiers, seems to have evolved over time. Depending on my fancy, I sometimes use variables like "OriginalValue" and sometimes "Starting-value". If the program is just for me, who cares? If the software is for a company, they will set the rules. Communities at large generate their own standards. Where it matters, people obey them. Where rules are set because it is supposed to be a "good thing", programmers take delight in breaking them. Personally, the rule "use only - or _ consistently throughout a module" reeks of a rule for rule's sake, one for the breaking. Damian's suggestion seems to me very useful because (for those that wish to follow it) it imposes an extra precision of thought, which almost always facilitates better programming. Adopting it will, I think, lead to more elegant code, for those that like that sort of thing. Regards, Richard
Re: underscores vs hyphens (was Re: A new era for Temporal)
Doug McNutt wrote: ${A-1} = 3.14159; $A = $A-1; $A = $A -1; $A-=2; $A = 123E-2; $A = Pi(); $B = sin ($A-1); $B = sin (${A}-1); $B = sin($A -1); -2**2 = -4 except when it comes out +4 as in MS Excel. _2**2 = +4 in some other languages that use _ as a unary minus operator. Will editors be bothered when I try to include "-" in the list of characters that are considered words when double clicking? When doing a find and replace all as words? Is the unicode equivalent of allowed in a variable name? See http://perlcabal.org/syn/S02.html#Names for your answers. Essentially, I believe that any character at all is allowed in a variable name. Its just that for most characters, when you use them the variable name has to be quoted. The common unquoted identifier syntax is much more limited, and is mainly what was being discussed here. -- Darren Duncan
Re: underscores vs hyphens (was Re: A new era for Temporal)
${A-1} = 3.14159; $A = $A-1; $A = $A -1; $A-=2; $A = 123E-2; $A = Pi(); $B = sin ($A-1); $B = sin (${A}-1); $B = sin($A -1); -2**2 = -4 except when it comes out +4 as in MS Excel. _2**2 = +4 in some other languages that use _ as a unary minus operator. Will editors be bothered when I try to include "-" in the list of characters that are considered words when double clicking? When doing a find and replace all as words? Is the unicode equivalent of allowed in a variable name? -- --> Give me liberty or give me Obamacare <--
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, 10 Apr 2010, Mark J. Reed wrote: I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. Ditto! If Perl 6 style is hyphens, use hyphens everywhere. That transition from P5 DateTime to P6 will then be a simple s/_/-/g -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: underscores vs hyphens (was Re: A new era for Temporal)
Em Dom, 2010-04-11 às 07:54 -0700, Damian Conway escreveu: > The relevant suggestion regarding hyphens vs underscores is: > "...to allow both characters, but have them mean the same thing." er... this smells like :: and ' in Perl 5... Which, while I find Acme::Don't amusing, cannot be stated as sane design... daniel
Re: underscores vs hyphens (was Re: A new era for Temporal)
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
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: Well, if we're not going to try to implement linguistically based hyphenation/underscoriation rules (and I'd still argue that hyphenating adjectives to nouns and underscoring everything else isn't exactly rocket science), then I'd suggest we reconsider a radically different proposal that was made on this list five years ago: http://www.mail-archive.com/perl6-langu...@perl.org/msg22675.html The relevant suggestion regarding hyphens vs underscores is: "...to allow both characters, but have them mean the same thing." I was about to say that if hyphens and underscores mean the same thing, then why are Perl 6's identifiers case sensitive? But, you know what, I haven't found any documentation stating they are. Could someone please give me the URI in the official documentation where this is stated. Thanks. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. Eliminate software piracy: use only FLOSS.
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is "correct". It's less "too subtle for JAPH" and more "too subtle for consensus even among the cognoscenti.". The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa wrote: > On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway wrote: >> Hyphen/underscore equivalence would allow those (apparently elite few) who >> can correctly use a hyphen to correctly use the hyphen > > That's about the only advantage of this scheme that I can think of. > The disadvantages, which affect everyone, are many and bigger: > search/replace headaches, novice confusion, adding to Perl's "syntax > infamy," etc. > > (Besides, I'm sure you can Acme::-up something that implements this > scheme in Perl 6 for your own devious purposes anyway… ;) > > -John > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
I can't help but agree with Damian. I don't see much of a point in making a distinction between - and _. More specifically, if a user were to define a function (say, i-hate-camel-case()), it would not be good to let them be the same. Readability would suffer when examining someone's code and you see i_hate_camel_case() and you can't find that function (in my example there are 8 different possibilities for what the actual function was defined as!) However, in "core" functionality, such a distinction should be made /if it makes sense/. For example, allowing 3 _ 4 in place of 3 - 4 would not make sense, while obscure commands (the PIR functions in rakudo, for example), would do better to not be so stringent (or at least tell you what you did wrong). This is my best guess based on what I know. I don't know the whole story, and I'm always ready to be convinced otherwise. -- Don't Panic!
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is "correct". It's less "too subtle for JAPH" and more "too subtle for consensus even among the cognoscenti.". The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa wrote: > On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway wrote: >> Hyphen/underscore equivalence would allow those (apparently elite few) who >> can correctly use a hyphen to correctly use the hyphen > > That's about the only advantage of this scheme that I can think of. > The disadvantages, which affect everyone, are many and bigger: > search/replace headaches, novice confusion, adding to Perl's "syntax > infamy," etc. > > (Besides, I'm sure you can Acme::-up something that implements this > scheme in Perl 6 for your own devious purposes anyway… ;) > > -John > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway wrote: > Hyphen/underscore equivalence would allow those (apparently elite few) who > can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's "syntax infamy," etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, 2010-04-10 at 17:20 -0700, yary wrote: > Adjectives and nouns aren't English-only. So Damian's proposal is > multi-culti. One could argue that Perl's identifiers, keywords, etc > are based on English so that it is more difficult for a non-English > speaker to discern why underscore is used in some places and hyphens > in other. The solution to that would be rote memorization of method > names, including "_" and "-" in the spelling. Not ideal, but most > likely what many English speaking programmers would do too. And would > cuss over. And there's the rub for me. One of the goals of Perl 6 is to reduce the amount of rote memorization of special cases that Perl 5 required. Any mixed use of _ and - in the standard setting defies that goal. (FWIW, I don't really care which is used -- I see arguments for both -- but I do firmly believe the standard setting should only use one or the other. Damian's Temporal example in which only one method used a different separator made the rules-versus-exceptions part of my brain scream for mercy.) -'f
Re: underscores vs hyphens (was Re: A new era for Temporal)
Well, if we're not going to try to implement linguistically based hyphenation/underscoriation rules (and I'd still argue that hyphenating adjectives to nouns and underscoring everything else isn't exactly rocket science), then I'd suggest we reconsider a radically different proposal that was made on this list five years ago: http://www.mail-archive.com/perl6-langu...@perl.org/msg22675.html 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. This would be the death of fine distinctions such as between: activate_main-sequence_detonator(); and: activate_main_sequence-detonator(); which would now resolve to the same subroutine...and do so even if that subroutine had been declared as sub activate-main-sequence-detonator {...} But perhaps such distinctions are indeed too fine and subtle, and we would be better off eliminating the possibility of them entirely. Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen, whilst the shambling masses can just randomly type underscores or hyphens between each word, as their atavistic whims dictate. ;-) Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:14 AM, Mark J. Reed wrote: > I'd much rather see a single consistent style throughout the setting > than backwards compatibility with p5 naming conventions. > > If Temporal is the first setting module to use multiword identifiers, > I vote for hyphens. As another data point ... me too. I'd prefer to see hyphens than underscores. -Scott > They're easier on the fingers and the eyes; > underscores have always felt like an ugly compromise to make the > compiler's job easier. > > On Saturday, April 10, 2010, Carl Mäsak wrote: > > John (>): > >> Forgive me if this is a question the reveals how poorly I've been > >> following Perl 6 development, but what's the deal with some methods > >> using hyphen-separated words (e.g., day-of-week) while others use > >> "normal" Perl method names (e.g., set_second)? > > > > I'd just like to point out that the current Temporal spec only does > > methods with underscores, including C. > > > > This goes against my personal preferences; I greatly prefer dashes in > > almost all of the code I write. But I acknowledge that most of the > > programmers out there seem to expect underscores -- and also, the aim > > was to produce a small delta from CPAN's DateTime and not change > > around things ad lib. > > > > // Carl > > > > -- > Mark J. Reed >
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 4:47 AM, Damian Conway wrote: > And is it really so hard to teach: "use underscore by default and reserve > hyphens for between a noun and its adjective"? Perhaps it *is*, but > then that's a very sad reflection on our profession. > If anything, it's a sad reflection on humanity. I don't see any special reason that our profession should be an exception to Sturgeon's law. And, IMHO, conventions should be such that every Joe-Coder should to be able to understand and use them, which means they should be as simple as possible. This thread itself proves that the choice of places where hyphen and underscore should be used under this scheme *feels* ambiguous, even if it strictly isn't so. I believe it would be best to have a rule for hyphen-or-underscore that can be mechanically applied. This would enable a perl6critic tool to check its proper usage, and more importantly, make the choice easy for Joe-Coder since he does not like to think much about function names. With such conventions, it is important to cater to mere mortals, since their code would form the bulk, which means a misunderstanding on their part would make their 'convention' the popular one, which is probably not a good thing. We might end up with PHP-ish nightmare of mixed conventions in function naming. I might go so far as to say that we could drop underscores altogether, and embrace the Lispy way of using hyphens everywhere. Easier to type, looks good, and simple to apply. My 2c, Sundar -- ! Knowing others is intelligence; knowing yourself is true wisdom. Mastering others is strength; mastering yourself is true power. ! If you realize that you have enough, you are truly rich.
RE: underscores vs hyphens (was Re: A new era for Temporal)
> From: Mark J. Reed [mailto:markjr...@gmail.com] [...] > Perl borrows vocabulary almost exclusively from English, but it is > not English, and its conventions are not those of English. (And the > conventions around hyphens that people are citing are quite specifically > those of standard written English; other writing systems, even those using > the same alphabet and mostly the same punctuation, have different rules). Consider s/English/Linux/ for example. :-) One consideration leading up to allowing "-" in P6 identifiers (initially in the context of an optional syntax-tweaking module) involved compatibility with fairly common usage in {directory and file} names (where spaces are avoided for cross-platform reasons). I've always thought {Lisp variable names and Unix/Linux file names} with hyphens (versus underscores) were {more readable and substantially easier to type (during long typing sessions)}. http://groups.google.com/group/perl.perl6.language/browse_thread/thread/1625baa7eead0d71/ http://groups.google.com/group/perl.perl6.compiler/browse_thread/thread/e6cc5dc9360ada36/c59f2fb1f49b80f5?lnk=gst&q=r28689#c59f2fb1f49b80f5 > I would personally like to see hyphens used as the standard word separator, > with underscores available for exceptions - say, naming a Perl interface > method exactly the same as the underlying C function it provides access to. [...] ++! Best regards, Conrad Conrad Schneiker www.AthenaLab.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Agreed. Perl borrows vocabulary almost exclusively from English, but it is not English, and its conventions are not those of English. (And the conventions around hyphens that people are citing are quite specifically those of standard written English; other writing systems, even those using the same alphabet and mostly the same punctuation, have different rules). I would personally like to see hyphens used as the standard word separator, with underscores available for exceptions - say, naming a Perl interface method exactly the same as the underlying C function it provides access to. I'd be less happy with underscores everywhere, but either of those solutions is better (IMESHO) than mixing hyphens and underscores, which should be avoided even within an API, never mind a single identifier. On Sat, Apr 10, 2010 at 8:55 PM, John Siracusa wrote: > On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso wrote: > > Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: > >> I'm having trouble imaging any convention that involves mixing word > >> separators being successful. > > > > But the convention Damian is proposing is simply "use underscores". > > > > Basically camelCase and with_underscores are conventions on "how to > > circunvent the fact that we can't use spaces in our identifiers". What > > is proposed here is that the p5 convention should be preserved. > > > > The hyphen is *not* a space, so it doesn't even get into the discussion > > of this convention. The basic difference is that when a programmer with > > sufficient communication skills have a composed word (i.e.: week-day), > > he will have the ability to use the hyphen instead of either supress it > > or use an underscore... > > These nuances are exactly what will be lost on people who see classes > that use both underscores and hyphens in their method names. > > -John > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso wrote: > Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: >> I'm having trouble imaging any convention that involves mixing word >> separators being successful. > > But the convention Damian is proposing is simply "use underscores". > > Basically camelCase and with_underscores are conventions on "how to > circunvent the fact that we can't use spaces in our identifiers". What > is proposed here is that the p5 convention should be preserved. > > The hyphen is *not* a space, so it doesn't even get into the discussion > of this convention. The basic difference is that when a programmer with > sufficient communication skills have a composed word (i.e.: week-day), > he will have the ability to use the hyphen instead of either supress it > or use an underscore... These nuances are exactly what will be lost on people who see classes that use both underscores and hyphens in their method names. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: > I'm having trouble imaging any convention that involves mixing word > separators being successful. But the convention Damian is proposing is simply "use underscores". Basically camelCase and with_underscores are conventions on "how to circunvent the fact that we can't use spaces in our identifiers". What is proposed here is that the p5 convention should be preserved. The hyphen is *not* a space, so it doesn't even get into the discussion of this convention. The basic difference is that when a programmer with sufficient communication skills have a composed word (i.e.: week-day), he will have the ability to use the hyphen instead of either supress it or use an underscore... daniel
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa wrote: > I'm not sure if the intersection of people who speak English and > people who program is better or worse than average when it comes to > grammar, but I do know (from editing my share of writing) that the > average is very bad and, further, that many programmers do not speak > English as a first language, or at all. Adjectives and nouns aren't English-only. So Damian's proposal is multi-culti. One could argue that Perl's identifiers, keywords, etc are based on English so that it is more difficult for a non-English speaker to discern why underscore is used in some places and hyphens in other. The solution to that would be rote memorization of method names, including "_" and "-" in the spelling. Not ideal, but most likely what many English speaking programmers would do too. And would cuss over.
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway wrote: > And is it really so hard to teach: "use underscore by default and reserve > hyphens for between a noun and its adjective"? Perhaps it *is*, but > then that's a very sad reflection on our profession. I'm not sure if the intersection of people who speak English and people who program is better or worse than average when it comes to grammar, but I do know (from editing my share of writing) that the average is very bad and, further, that many programmers do not speak English as a first language, or at all. I'm having trouble imaging any convention that involves mixing word separators being successful. Maybe a completely deterministic one like "hyphens after vowels, underscores after consonants," but that's pretty nonsensical. I think it has to be all hyphens or all underscores within a single method name, with the only wiggle room being a possible convention that dictates a different word separator for different kinds of methods. (My personal preference: methods_like_this(), just like in Perl 5. My second choice: methods-like-this(). Either way, no grammar knowledge required beyond knowing where one word ends and another begins—and even that's not a universal skill!) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
John Siracusa commented: > That's certainly an example of how hyphens might gain meaning in Perl > 6 names, but I don't think I can endorse it as a convention. People > can't even use hyphens correctly in written English. I have very > little faith that programmers will do any better in code But then the only alternative is to suffer under Slartibartfast's Conundrum: Slartibartfast: I'd much rather be happy than right, any day. Arthur Dent: And are you? Slartibartfast: Ah, well...that's where it all falls down, of course. ;-) And is it really so hard to teach: "use underscore by default and reserve hyphens for between a noun and its adjective"? Perhaps it *is*, but then that's a very sad reflection on our profession. I'm certainly not saying we mightn't collectively find a better (more useful) rule, but that one doesn't strike me as particularly hard. Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
In English, hyphens normally indicate an extra level of reification, where e.g. what is normally a phrase is used in a context that requires a single word: "The miller gave us the run of the mill." vs. "It was a run-of-the-mill event." As such, examples like "day?of?week" are somewhat infelicitous, as they could go either way depending on context. In fact, I'd be tempted to go with the punctuation-free "weekday", despite spoiling the nice parallelism with "day?of?month", "year", etc. (Perhaps a generic day_of() that takes a keyword argument would be a useful addition?) But that's going off the track (or off-track). Programming statements do not, in general, read like English, and as such, trying to apply English punctuation rules will at best yield ambiguous results. On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway wrote: > Personally, I'd prefer to see the English conventions carried over to > the use of general use of hyphen and underscore in identifiers in > the core (and everywhere else). > > By that, I mean that, in English, the hyphen is notionally a > "higher precedence" word-separator than the space > (or than its intra-identifier stand-in: the underscore). > > For example: there's an important difference between: > >initiate_main-sequence_detonator_phase() > > and: > >initiate_main_sequence-detonator_phase() > > The former initiates the detonator phase for the main sequence; > the latter initiates the main phase of the sequence detonator. > > More simply, there's a difference between: > > $obj1.set_difference($obj2); > > and: > > $obj1.set-difference($obj2); > > The first is setting a difference; the second is computing a > difference-of-sets. > > The rule I intend to use and recommend when employing this new > identifier character in multiword names is that you should place an > underscore between "ordinary unrelated" words, and a hyphen only > between a word and some modifier that applies specifically to that word. > > Which, if applied to Temporal, would lead to: > >my $now = DateTime.from_epoch(time); > >The C method also has the synonym C. > >(These are also available through the methods C and >C, respectively.) > >There's a C method, > >The C method returns a number 1..5 > >The C method returns the day of the quarter. > >The C method returns the day of the year, > >The method C returns the second truncated to an integer. > >The C method returns the C object > > (i.e. only C<.from_epoch()> actually uses underscore). > > Oh, and the optional C<:timezone> argument to C<.new()> should probably > become C<:time-zone> for consistency with the C<.time-zone()> method > (or, preferably, we should jut bite the bullet and go with C > throughout). > > Damian > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway wrote: > Personally, I'd prefer to see the English conventions carried over to > the use of general use of hyphen and underscore in identifiers in > the core (and everywhere else). That's certainly an example of how hyphens might gain meaning in Perl 6 names, but I don't think I can endorse it as a convention. People can't even use hyphens correctly in written English. I have very little faith that programmers will do any better in code, leading to the worst of all possible worlds: a convention that is confusing and employed incorrectly much of the time. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a "higher precedence" word-separator than the space (or than its intra-identifier stand-in: the underscore). For example: there's an important difference between: initiate_main-sequence_detonator_phase() and: initiate_main_sequence-detonator_phase() The former initiates the detonator phase for the main sequence; the latter initiates the main phase of the sequence detonator. More simply, there's a difference between: $obj1.set_difference($obj2); and: $obj1.set-difference($obj2); The first is setting a difference; the second is computing a difference-of-sets. The rule I intend to use and recommend when employing this new identifier character in multiword names is that you should place an underscore between "ordinary unrelated" words, and a hyphen only between a word and some modifier that applies specifically to that word. Which, if applied to Temporal, would lead to: my $now = DateTime.from_epoch(time); The C method also has the synonym C. (These are also available through the methods C and C, respectively.) There's a C method, The C method returns a number 1..5 The C method returns the day of the quarter. The C method returns the day of the year, The method C returns the second truncated to an integer. The C method returns the C object (i.e. only C<.from_epoch()> actually uses underscore). Oh, and the optional C<:timezone> argument to C<.new()> should probably become C<:time-zone> for consistency with the C<.time-zone()> method (or, preferably, we should jut bite the bullet and go with C throughout). Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
Mark (>>), John (>): >> I'd much rather see a single consistent style throughout > > Yeah, that's was my main point/question. I wanted to know if it was > it some intentional convention (e.g., "all methods that change the > object state use hyphens, and all others use underscores") or if it > was just meaningless inconsistency. John, where is the inconsistency of which you write? Curious, I grepped through Temporal.pm in search for hyphens in method names, but found none. // Carl
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed wrote: > I'd much rather see a single consistent style throughout Yeah, that's was my main point/question. I wanted to know if it was it some intentional convention (e.g., "all methods that change the object state use hyphens, and all others use underscores") or if it was just meaningless inconsistency. Perl 6 does need some sort of convention in this area. Since it has a wider range of possible method names, there are more options. It took a little while for Perl 5 to converge on method_names_like_this() (after trying methodNamesLikeThis and LikeThis and so on), but many of those experiments and false starts still linger on CPAN and in end-user code. It'd be nice to avoid all that in Perl 6. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens. They're easier on the fingers and the eyes; underscores have always felt like an ugly compromise to make the compiler's job easier. On Saturday, April 10, 2010, Carl Mäsak wrote: > John (>): >> Forgive me if this is a question the reveals how poorly I've been >> following Perl 6 development, but what's the deal with some methods >> using hyphen-separated words (e.g., day-of-week) while others use >> "normal" Perl method names (e.g., set_second)? > > I'd just like to point out that the current Temporal spec only does > methods with underscores, including C. > > This goes against my personal preferences; I greatly prefer dashes in > almost all of the code I write. But I acknowledge that most of the > programmers out there seem to expect underscores -- and also, the aim > was to produce a small delta from CPAN's DateTime and not change > around things ad lib. > > // Carl > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
John (>): > Forgive me if this is a question the reveals how poorly I've been > following Perl 6 development, but what's the deal with some methods > using hyphen-separated words (e.g., day-of-week) while others use > "normal" Perl method names (e.g., set_second)? I'd just like to point out that the current Temporal spec only does methods with underscores, including C. This goes against my personal preferences; I greatly prefer dashes in almost all of the code I write. But I acknowledge that most of the programmers out there seem to expect underscores -- and also, the aim was to produce a small delta from CPAN's DateTime and not change around things ad lib. // Carl