The faulty test was fixed in the 6.c-errata branch with commit 6af3c5b5de.
I'm closing this ticket as 'resolved'.
ata roast branch:
not ok 196 - adding a day to a leap second
# Failed test 'adding a day to a leap second'
# at t/spec/S32-temporal/DateTime.t line 504
# expected: '2009-01-02T00:00:00Z'
# got: '2009-01-01T23:59:59Z'
--
Will "Coke" Coleda
The test failures in S32-temporal/Date* are gone. For parrot there was a commit
from lizmat++ which fixed the issue:
https://github.com/rakudo/rakudo/commit/a640aab02f8fb73f64693ee3e5301ffc15bed748
I'm closing this ticket now.
AFAIU this was fixed with the following commit, which explicitly sets the
timezone to America/New_York:
https://github.com/perl6/roast/commit/04d38c8a3cc04519dfd213c6281186cbd67cce51
If that was not what you meant, please reopen the ticket.
ent updates force a value for $*TZ, but this causes
several test failures, with results like:
not ok 25 - DateTime.local (from UTC, with leap second)
# Failed test 'DateTime.local (from UTC, with leap second)'
# at t/spec/S32-temporal/local.t line 1
# expected: '1998-12-31T18:59:6
# New Ticket Created by Will Coleda
# Please include the string: [perl #122681]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122681 >
S32-temporal/Date.t, S32-temporal/DateTime-Instant-Duration.t,
S32-temporal/DateTim
# New Ticket Created by Carlin Bingham
# Please include the string: [perl #122319]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122319 >
The tests at the bottom of S32-temporal/local.t are skipped on systems where
-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
-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
-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
hanged paths:
M S32-setting-library/Temporal.pod
Log Message:
---
Updated Temporal reflecting Int-only Timezones.
Hi Carl,
On 02/19/2013 02:03 PM, Carl Franks wrote:
S32/Temporal says a DateTime object can be maniplated like so:
$dt.delta(44, minutes);
Rakudo's core/Temporal.pm contains this:
my enum TimeUnit (
:second(1), :seconds(2),
:minute(3), :minutes(4),
Greetings,
S32/Temporal says a DateTime object can be maniplated like so:
$dt.delta(44, minutes);
Rakudo's core/Temporal.pm contains this:
my enum TimeUnit (
:second(1), :seconds(2),
:minute(3), :minutes(4),
[snip]
);
which is used in the signature of
-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.
-setting-library/Exception.pod
Log Message:
---
[S32::Exception] make X::Temporal a role
Hello,
I believe this bug can be marked as 'resolved'. It works in current
rakudo and has an active and passing test in S05-capture/caps.t
Cheers,
Fitz Elliott
/Temporal.pod
Log Message:
---
[S32/Temporal] Graduated out of draft state and corrected my description of the
offset method.
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
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
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
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
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
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
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
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
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
-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
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
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
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/
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
I find the motivation to hand-apply it.
>
> (Seriously, git could do better, IMHO)
>
>
0001-Temporal-Date-modifications-and-refactoring.patch
Description: Binary data
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
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:
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/
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
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
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
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
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
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
# New Ticket Created by Timothy Totten
# Please include the string: [perl #76376]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=76376 >
Find attached a patch which implements several changes to the Temporal and
D
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #75484]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75484 >
'a b c d' ~~ /:s [(\w) ]+/;
say $0.WHAT;
say $0.elems;
say $.WHAT;
say $.elems;
say $/;
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
${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
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/_/-
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
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
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
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
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
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
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
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
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
-
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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.
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
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
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
1 - 100 of 216 matches
Mail list logo
