[perl6/specs] b414bc: Revert "[S32::Temporal] Expand valid ISO 8601 form...

-setting-library/Temporal.pod Log Message: --- Revert "[S32::Temporal] Expand valid ISO 8601 formats." ISO 8601 is a good thing, but that does not mean *all* of it is a good thing. Specifiacally, allowing week specifications in the DateTime core will make the logic even more c

[perl6/specs] 1735a4: [S32::Temporal] Change added Duration info to Inte...

-library/Temporal.pod Log Message: --- [S32::Temporal] Change added Duration info to Interval. Yes, we just made a brand new object. Some new issuess, including the / form of ISO 8601 intervals, Duration <-> Interval conversion (potentially), and describing Interval in other loc

[perl6/specs] c32379: [S32::Temporal] Add Duration object.

-library/Temporal.pod Log Message: --- [S32::Temporal] Add Duration object. Allows creation similar to DateTime objects and provides some accessor methods (the Duration in years, or days, etc.). Commit: 97c5bc4e47b819b640fc5f815b861d753ed8aa9c https://github.com/perl6/specs

[perl6/specs] 5692ce: Updated Temporal reflecting Int-only Timezones.

hanged paths: M S32-setting-library/Temporal.pod Log Message: --- Updated Temporal reflecting Int-only Timezones.

[perl6/specs] 9d8bc5: [S32/Temporal] spec DateTime.delta and Date.delta

-setting-library/Temporal.pod Log Message: --- [S32/Temporal] spec DateTime.delta and Date.delta Clarify the .truncated-to method as well; it also uses the C enum, instead of named parameters.

[perl6/specs] 331a25: [S32::Exception] make X::Temporal a role

-setting-library/Exception.pod Log Message: --- [S32::Exception] make X::Temporal a role

[perl6/specs] 5994eb: [S32/Temporal] Graduated out of draft state and co...

/Temporal.pod Log Message: --- [S32/Temporal] Graduated out of draft state and corrected my description of the offset method.

r31835 -[S32/Temporal] Specified how DateTime.new(Int) should interpret ambiguous input.

Author: Kodi Date: 2010-07-26 15:57:17 +0200 (Mon, 26 Jul 2010) New Revision: 31835 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Specified how DateTime.new(Int) should interpret ambiguous input. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod

r31820 -[S32/Temporal] Fixed an inconsistency and uniquified a section title to avoid confusing smartlinks.pl.

Author: Kodi Date: 2010-07-25 01:41:01 +0200 (Sun, 25 Jul 2010) New Revision: 31820 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Fixed an inconsistency and uniquified a section title to avoid confusing smartlinks.pl. Modified: docs/Perl6/Spec/S32-setting

Re: r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just impl

n: 31777 > > Modified: >   docs/Perl6/Spec/S32-setting-library/Temporal.pod > Log: > [S32/Temporal] Reverted DateTime back to being mutable. I think we ought to > make a big change like this only after reaching some kind of consensus to do > so, not least because I just implem

Re: r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just implem

pugs-comm...@feather.perl6.nl wrote: Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just

r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just implemente

Author: Kodi Date: 2010-07-21 02:12:24 +0200 (Wed, 21 Jul 2010) New Revision: 31777 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of

Re: r31776 -[S32/Temporal] Make DateTime immutable.

On Tue, Jul 20, 2010 at 5:51 PM, wrote: > +C objects are immutables. > + I think just the adjective works better here ("are immutable")... but more to the point: > +A C can also be created by modifying an existing object: It's mildly confusing to say they're immutable and then turn around and

r31776 -[S32/Temporal] Make DateTime immutable.

Author: dolmen Date: 2010-07-20 23:51:26 +0200 (Tue, 20 Jul 2010) New Revision: 31776 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Make DateTime immutable. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

More importantly, it's already in the spec! All I proposed was an alias to an existing attribute name. If it gets dropped out of core, that's fine, too. But I'd like to see the longer name available, in whatever module it shows up in... On Thu, Jul 15, 2010 at 5:36 PM, yary wrote: > On Thu, J

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

On Thu, Jul 15, 2010 at 2:13 PM, Brandon S Allbery KF8NH wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 7/15/10 12:21 , Mark J. Reed wrote: >> By analogy, I'd say week-of-year should work as well. > > Wasn't the week stuff punted to a non-core module because there are too many > d

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/15/10 12:21 , Mark J. Reed wrote: > By analogy, I'd say week-of-year should work as well. Wasn't the week stuff punted to a non-core module because there are too many differences in how it's handled (week starts on Sunday in the US and Israel and

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

I was just proposing an alias for "week" it that clarifies what it is the week *of*. The rest of what you ask is already established in Temporal.pm. 1. week returns the week number in the ISO 8601 week calendar. You can find the spec by Googling, but in summary: a. weeks begin on Monday

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

On Thu, Jul 15, 2010 at 9:21 AM, Mark J. Reed wrote: > By analogy, I'd say week-of-year should work as well. Oof, is there a generally accepted for numbering weeks within a year? A month's boundaries' always coincides with a day's boundary, but a year only occasionally begins/ends on a week bound

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

By analogy, I'd say week-of-year should work as well. On Thu, Jul 15, 2010 at 8:18 AM, wrote: > Author: Kodi > Date: 2010-07-15 14:18:15 +0200 (Thu, 15 Jul 2010) > New Revision: 31696 > > Modified: >   docs/Perl6/Spec/S32-setting-library/Temporal.pod > Log: > [S32/

r31696 -[S32/Temporal] Permit day-of-month on Dates.

Author: Kodi Date: 2010-07-15 14:18:15 +0200 (Thu, 15 Jul 2010) New Revision: 31696 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Permit day-of-month on Dates. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod

r31689 -[S32/Temporal] Permit days-in-month and is-leap-year on DateTimes, too.

Author: Kodi Date: 2010-07-14 23:18:42 +0200 (Wed, 14 Jul 2010) New Revision: 31689 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Permit days-in-month and is-leap-year on DateTimes, too. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod

r31680 -[S32/Temporal] Added to Date: "There are also C, C, C, C, and C methods, which work just like their DateTime equivalents."

Author: Kodi Date: 2010-07-14 16:35:46 +0200 (Wed, 14 Jul 2010) New Revision: 31680 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Added to Date: "There are also C, C, C, C, and C methods, which work just like their DateTime equivalents." Modified:

r31678 -[S32/Temporal] DateTime.new(Numeric) -> DateTime.new(Int), since time no longer returns fractional seconds.

Author: Kodi Date: 2010-07-14 16:02:34 +0200 (Wed, 14 Jul 2010) New Revision: 31678 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] DateTime.new(Numeric) -> DateTime.new(Int), since time no longer returns fractional seconds. Modified: docs/Perl6/Spec/

r31652 -[Temporal] time is now a pseudo-constant like now, rand, etc

Author: lwall Date: 2010-07-13 02:06:01 +0200 (Tue, 13 Jul 2010) New Revision: 31652 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [Temporal] time is now a pseudo-constant like now, rand, etc Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod

Re: r31627 -[S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal.

Scott (>): > Perhaps it's just me, but a boolean value to specify the direction of > conversion seems wrong-ish. It's not just you. :) // Carl

Re: r31627 -[S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal.

On Sun, Jul 11, 2010 at 12:56 PM, wrote: > Author: Kodi > Date: 2010-07-11 19:56:33 +0200 (Sun, 11 Jul 2010) > New Revision: 31627 > > Modified: > docs/Perl6/Spec/S32-setting-library/Temporal.pod > Log: > [S32/Temporal] Changed to use a different way of specifyin

r31627 -[S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal.

Author: Kodi Date: 2010-07-11 19:56:33 +0200 (Sun, 11 Jul 2010) New Revision: 31627 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal. Modified: docs/Perl6

r31600 -[S32/Temporal] Prose edit; "C" -> "list"

Author: Kodi Date: 2010-07-09 21:47:34 +0200 (Fri, 09 Jul 2010) New Revision: 31600 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Prose edit; "C" -> "list" Modified: docs/Perl6/Spec/S32-setti

r31598 -[S32/Temporal] Clarified the distinction between &time and &now, specified what formatters and time zones should actually do, and dropped some formatting methods.

Author: Kodi Date: 2010-07-09 19:43:53 +0200 (Fri, 09 Jul 2010) New Revision: 31598 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Clarified the distinction between &time and &now, specified what formatters and time zones should actually do, and drop

Re: Proposal for a new Temporal time-measurement paradigm

On Sun, Apr 25, 2010 at 02:31, Doug McNutt wrote: > Agree on a format for storing fractional atomic seconds. There are > proposals for two word integers with one of them being micro or nano seconds > and the other seconds. I prefer IEEE floating point with atomic seconds as > the unit of measure

Re: Proposal for a new Temporal time-measurement paradigm

At 21:09 -0700 4/23/10, Darren Duncan wrote: >I think that the most thorough solution is to just take it for granted that >there are multiple reference timelines/calendars and that in general it is >impossible to reconcile them with each other. At 15:46 -0700 4/24/10, Darren Duncan wrote: >All d

Re: Proposal for a new Temporal time-measurement paradigm

gument for Perl packagers to bundle Gregorian-knowledgeable temporal modules, so that users get them by default. But then there would also be a package-managing system for more easily keeping those non-core components updated as new time-zone databases or leap-second measurements are made. My arg

Re: Proposal for a new Temporal time-measurement paradigm

Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. On Saturday, April 24, 2010, Darren Duncan wrote: > I want to clarify that I currently believe that the Perl 6 core should only > include temporal roles and *no* te

Re: Proposal for a new Temporal time-measurement paradigm

On Sun, Apr 25, 2010 at 00:46, Darren Duncan wrote: > All details specific to any calendar, including Gregorian, including > concepts like seconds or hours or days, should be left out of the core and > be provided by separate modules. Said modules can be self-contained, just > say using Perl's or

Re: Proposal for a new Temporal time-measurement paradigm

I want to clarify that I currently believe that the Perl 6 core should only include temporal roles and *no* temporal classes. So the Perl 6 core could provide, say, 3 roles, Instant, Duration, and Calendar (or use some other name for the last one). It would also provide now(), sleep(), and

Re: Proposal for a new Temporal time-measurement paradigm

And so, what we can do in general is simply have an Instant role and a Duration role, and pairs of types where each member composes one of those, and then all that needs to exist for temporal routines is an independent collection for each pair that is closed within that pair. This is what I wa

Re: Proposal for a new Temporal time-measurement paradigm

e can do in general is simply have an Instant role and a > Duration role, and pairs of types where each member composes one of those, > and then all that needs to exist for temporal routines is an independent > collection for each pair that is closed within that pair. This is what I was tryi

Re: Proposal for a new Temporal time-measurement paradigm

and pairs of types where each member composes one of those, and then all that needs to exist for temporal routines is an independent collection for each pair that is closed within that pair. Each instant simply says, "I am this point on this particular timeline/calendar", and not try

Re: Proposal for a new Temporal time-measurement paradigm

Why do I find myself thinking of roles and classes here? IMHO, we should have a role that represents abstractly a moment in time. This role should, in and of itself, not be tied to any particular calendar; its purpose is so that one can write functions that make reference to instances in time wit

Re: Proposal for a new Temporal time-measurement paradigm

Minor nit: On Apr 21, 2010, at 04:57 , Richard Hainsworth wrote: If a calendar system, eg., Chinese, Muslim and Jewish, defines days in the same way, eg., starting at midnight and incorporating leap seconds, for a time-zone, then the naming of the days is done by The Jewish, Muslim, and Bah

Re: Proposal for a new Temporal time-measurement paradigm

On Wed, 21 Apr 2010, Mark J. Reed wrote: I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendr

Re: Proposal for a new Temporal time-measurement paradigm

I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. Also, the difference bet

Re: Proposal for a new Temporal time-measurement paradigm

I whole-heartedly agree that we need to make a system independent of any sort of time measurement system. I think the conclusion reached on IRC was that most of the world uses or is at least familiar with the Gregorian system. Now, I can't help but think how we would define an Instant. The bes

Proposal for a new Temporal time-measurement paradigm

In reading all of the discussion about Temporal, I have the uneasy feeling that the current development work is falling into the same traps as other languages. It seems to me that the underlying time-measurement paradigm of the developers is too tightly focused on the Christian Gregorian

Re: A new era for Temporal

On Mon, 12 Apr 2010, Moritz Lenz wrote: Am 12.04.2010 03:47, schrieb Dave Rolsky: On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is

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 n

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 >

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

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

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

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 a

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

Re: A new era for Temporal

Am 12.04.2010 03:47, schrieb Dave Rolsky: On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out

Re: A new era for Temporal

On Mon, Apr 12, 2010 at 6:38 AM, Mark J. Reed wrote: > I think that having a standard, minimal API for this defined in core as a >> Date role would be ideal. > > > Agreed. In fact, I'd like to see DateTime be defined explicitly as a > superset (subrole) of Date, with a method for extracting just

Re: A new era for Temporal

On Sun, Apr 11, 2010 at 9:47 PM, Dave Rolsky wrote: > On Sun, 11 Apr 2010, Moritz Lenz wrote: > > I've planned to add such a module to the Perl 6 spec, but some comments >> on #perl6 suggested it should be kept out of core to prevent bloat. >> Still if the overall opinion is that Perl 6 should h

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 sp

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 bothere

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 inclu

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/_/-

Re: expression of seconds (was Re: A new era for Temporal)

On Fri, 9 Apr 2010, Darren Duncan wrote: conceptual and a usability and a math point of view. If users only want the integer value, then they can just store the second as an integer in the first place. As for the name, well "whole_second" can be made shorter, or its Users will not always co

Re: A new era for Temporal

On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out of the box, I'll be happy to spec it. I

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 a

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 th

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 p

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 wh

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 y

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 wh

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

Re: underscores vs hyphens (was Re: A new era for Temporal)

- 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: A new era for Temporal

Dave Rolsky wrote: > On Thu, 8 Apr 2010, Carl Mäsak wrote: > >> I do want to explicitly credit Dave Rolsky, whose work on the DateTime >> family of modules on CPAN has informed much of the current spec, >> sometimes to the point of verbatim copying. > > Thanks, but I'd hate to see you copy all my

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 o

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 hyphen

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 h

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

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 sa

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". > > Basic

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 c

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, th

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

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 Bu

Re: underscores vs hyphens (was Re: A new era for Temporal)

gt; 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, an

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

Re: underscores vs hyphens (was Re: A new era for Temporal)

oying 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.

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

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 unde

Re: A new era for Temporal

Is Int a proper type? I hope I can use basic operation within Date and hours in perl6 like: Date -1/24 + 1/24/60 + Date On Fri, Apr 9, 2010 at 10:00 PM, Moritz Lenz wrote: > Am 09.04.2010 15:33, schrieb Dave Rolsky: > > On Thu, 8 Apr 2010, Carl Mäsak wrote: >> >> I do want to exp

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 fe

Re: underscores vs hyphens (was Re: A new era for Temporal)

)? 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 underscor

underscores vs hyphens (was Re: A new era for Temporal)

he middle of a bareword string, but I can understand why it was done. And so, if the language supports it and it is reasonable, why not use it? 2. I do think that any particular module should be internally consistent in its naming scheme, so Temporal should use all-underscores or all-hyph

Re: A new era for Temporal

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)? -John

Re: A new era for Temporal

On Thu, 8 Apr 2010, Carl Mäsak wrote: We (mberends and masak) just pushed a commit to S32::Temporal which completely replaces what we had before. The changes are rooted in hours of discussion on #perl6, and we feel rather more confident with what we have now than with what we had before. That

Re: expression of seconds (was Re: A new era for Temporal)

On Fri, Apr 9, 2010 at 3:06 PM, Jonathan Worthington wrote: > Though even clearer and same number of characters as whole_seconds is: > > $dt.seconds.round This makes more sense to me than the first example you listed because when dealing with time measurement, I rarely think of seconds that ar

Re: expression of seconds (was Re: A new era for Temporal)

Jonathan Worthington wrote: Darren Duncan wrote: Dave Rolsky wrote: On a smaller point, I think second vs whole_second is the wrong Huffman coding. I'd think most people want the integer value. Well, whatever you call things, the most important thing is to keep the seconds count as a single

Re: expression of seconds (was Re: A new era for Temporal)

Darren Duncan wrote: Dave Rolsky wrote: On a smaller point, I think second vs whole_second is the wrong Huffman coding. I'd think most people want the integer value. Well, whatever you call things, the most important thing is to keep the seconds count as a single number which can do fractions

expression of seconds (was Re: A new era for Temporal)

Dave Rolsky wrote: On a smaller point, I think second vs whole_second is the wrong Huffman coding. I'd think most people want the integer value. Well, whatever you call things, the most important thing is to keep the seconds count as a single number which can do fractions, or if you really mus

Re: A new era for Temporal

Am 09.04.2010 15:33, schrieb Dave Rolsky: On Thu, 8 Apr 2010, Carl Mäsak wrote: I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. Thanks, but I'd hate to see you c

Re: A new era for Temporal

On Thu, 8 Apr 2010, Carl Mäsak wrote: I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. Thanks, but I'd hate to see you copy all my mistakes too! One thing I think

Re: A new era for Temporal

Mark (>): > This looks much better.  Thank you.  When can we expect to see the new > version implemented in Rakudo?  Need any help on that front? A preliminary version is already checked in, and works. It's not full-featured yet, but work is underway. Commits are appreciated, as always.

Re: A new era for Temporal

This looks much better. Thank you. When can we expect to see the new version implemented in Rakudo? Need any help on that front? On Thu, Apr 8, 2010 at 5:52 PM, Carl Mäsak wrote: > We (mberends and masak) just pushed a commit to S32::Temporal which > completely replaces what we had

  1   2   3   >