On Tue, Jul 05, 2005 at 03:48:47PM -0700, Dave Whipp wrote:
: Dave Whipp wrote:
:
: >You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
: >last one is not "{+time}", because that would be a floating-point value,
: >not an integer).
Or {time.int}, presumably.
: I was thinki
Again with the metamodel stuff :P
So, I am trying to implement the submethods correctly, and some
questions occurred to me.
The concept of non-inherited infrastructural methods is fairly simple
to accomplish in the meta-model, by just giving submethods their own
dispatch table inside the met
Larry,
On Jul 5, 2005, at 9:08 PM, Larry Wall wrote:
If we pretend attribute declarations are anonymous role declarations,
they might
turn out to be just that, especially if we decide it's a useful
conceit.
This exact thing occurred to me as I was sitting in traffic on the way
back from $wor
On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote:
: Hmmm Actually, ntpd achieves that sort of accuracy -- but if
: I understand correctly it anchors the UTC time to the standard,
: and allows the UNIX seconds count (which often does not account for
: new leap seconds, though some gmtime v
On Tue, Jul 05, 2005 at 05:26:31PM -0400, Stevan Little wrote:
: What should I do when I encounter two attributes which can peacefully
co-exist as
: attributes, but cause a class when we autogenerate the accessors for them.
Here is a
: quick example:
:
: class Foo {
: has @.bar;
:
On Jul 5, 2005, at 6:18 PM, Sam Vilain wrote:
Craig DeForest wrote:
Using the TAI epoch of 1958-01-01 00:00:00 has several advantages:
- TAI is recognized by international standards-setting bodies
(BIPM).
- Perl6 will then shake out the 31-bit time rollover a full 12
years before
Craig DeForest wrote:
Using the TAI epoch of 1958-01-01 00:00:00 has several advantages:
- TAI is recognized by international standards-setting bodies (BIPM).
- Perl6 will then shake out the 31-bit time rollover a full 12 years before
I like this in principle, however I wonder of the
Dave Rolsky skribis 2005-07-05 15:41 (-0500):
> As for 0 vs 1 as the index, I think this is a bit of a red herring. If
> you're constantly using this as an array index you're operating at too low
> a level (IMO). If all your programs start with:
> my @DayNames = qw( Sunday Monday Tuesday ... )
Hello,
As I am building the metamodel, I had a question, I did not find anything
specifically in
the docs regarding this.
What should I do when I encounter two attributes which can peacefully co-exist
as
attributes, but cause a class when we autogenerate the accessors for them. Here
is a
qu
On Tue, 5 Jul 2005, Juerd wrote:
No. Humans don't USE numbers for week days! So beginning at 1 makes no
sense, except for humans who like creating lists like (undef, ). In fact, I would prefer to
not having any 0 :)
This should be separated into day() and day_name(). It's hardly obvious
tha
Darren Duncan wrote:
Actually, there was a big oversight in my last message. It does not
handle approximate or relative dates, such as when you don't know the
details.
FWIW, this is handled by DateTime::Incomplete, and also will be natively
supported by Date::Gregorian.
You're describing wit
At 3:36 PM -0700 7/5/05, Dave Whipp wrote:
Darren Duncan wrote:
The object should not store anything other than this single
numerical value internally (smart caching of conversions aside).
I think we can all either agree with that, or dont-care it. The
internal implementation is an implementa
Quoth Craig DeForest on Tuesday 05 July 2005 04:59 pm,
> ...This is important
> because, without proper maintenance of the leap-second table, all of our
> perl6 calendar programs will run an hour late a mere 500 years from now.
Uh, sorry -- "...an hour fast a mere 500 years from now."
Quoth Darren Duncan on Tuesday 05 July 2005 04:20 pm,
> I believe that at its core [the time/date] object should simply store a
count of
> rigorously defined time units relative to a rigorously defined epoch.
> What the epoch is and what the time unit is will need to be
> officially defined (eg,
Actually, there was a big oversight in my last message. It does not
handle approximate or relative dates, such as when you don't know the
details.
My previous proposal should be restricted specifically to the
situations where you know the date/time to a high precision, to the
second. So my
Dave Whipp wrote:
You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
last one is not "{+time}", because that would be a floating-point value,
not an integer).
I was thinking: an epoch is just a time, and "int time" is a duration --
the number of seconds since the current
Darren Duncan wrote:
The object
should not store anything other than this single numerical value
internally (smart caching of conversions aside).
I think we can all either agree with that, or dont-care it. The internal
implementation is an implementation issue (or library). It doesn't need
t
All,
In the spirit of forward thinking and adaptability (and
internationalization), I believe a core Time/Date object should be
calendar agnostic and simply store some value that is easily
convertable to any date + time on any calendaring system. I say
forward thinking because this system wi
Douglas P. McNutt wrote:
At 10:55 -0700 7/5/05, Dave Whipp wrote:
I don't understand why time() should return a numeric value at all.
Some of us like to use epoch time, as an integer, to create unique file names which sort
"right" in a shell or GUI.
You can use "{time - $epoch}" or "{time
At 10:55 -0700 7/5/05, Dave Whipp wrote:
>I don't understand why time() should return a numeric value at all.
Some of us like to use epoch time, as an integer, to create unique file names
which sort "right" in a shell or GUI.
--
--> From the U S of A, the only socialist country that refuses to
Hi,
Juerd wrote:
> Ingo Blechschmidt skribis 2005-07-05 20:08 (+0200):
>> FWIW, I agree, but I'd like to propose standard overloadings:
>> say ~$time; # "Di 05 Jul 2005 20:01:42 CEST"
>
> Or perhaps not. In fact, rather not. Please let stringification be the
> ISO standard, and otherwis
Dave Rolsky skribis 2005-07-05 11:41 (-0500):
> >* .month and .wday are one-based. Sunday == 1. Haskell has them as
> > enums which avoids off-by one confusion completely; I made them like
> > I did because that's like humans think of them.
> And yes again!
No. Humans don't USE numbers for week
Ingo Blechschmidt skribis 2005-07-05 20:08 (+0200):
> FWIW, I agree, but I'd like to propose standard overloadings:
> say ~$time; # "Di 05 Jul 2005 20:01:42 CEST"
Or perhaps not. In fact, rather not. Please let stringification be the
ISO standard, and otherwise certainly sortable: year f
Hi,
Dave Whipp wrote:
> Larry Wall wrote:
>> The time function always returns the time in floating point.
>
> I don't understand why time() should return a numeric value at all.
> Surely it should return a DateTime (or Time) object. Using epochs in a
> high level language seems like a really bad
Larry Wall wrote:
The time function always returns the time in floating point.
I don't understand why time() should return a numeric value at all.
Surely it should return a DateTime (or Time) object. Using epochs in a
high level language seems like a really bad thing to be doing. If I want
On Tue, 5 Jul 2005, Gaal Yahas wrote:
Regarding Time::Local fields, it's an object now, so the order of things
Should that be Time::localtime? In P5 there are Time::localtime &
Time::gmtime, which are thin OO facades over the language builtins. Then
there's the module Time::Local, which is
On Tue, Jul 05, 2005 at 11:41:23AM -0500, Dave Rolsky wrote:
> >Regarding Time::Local fields, it's an object now, so the order of things
>
> Should that be Time::localtime? In P5 there are Time::localtime &
> Time::gmtime, which are thin OO facades over the language builtins. Then
> there's th
On Tue, Jul 05, 2005 at 08:16:54AM -0700, Larry Wall wrote:
> I don't think either of those are good human engineering. I would
> like the preferred Perl 6 form to simply be:
>
> multi sub localtime(Num $?when = time) returns Time::Local { ... }
Done.
I take it that the rest is okay? If so
On Tue, Jul 05, 2005 at 04:39:48PM +0300, Gaal Yahas wrote:
: As for the function signatures:
:
:multi sub localtime(Rat $?when = time) returns Time::Local { ... }
:multi sub localtime(Int $sec, Int ?$pico = 0) returns Time::Local {...}
:
: The first form uses the second, but might be les
I've added localtime to pugs (r5233, 5236), to address Dave Rolsky's needs
for DateTime; but I'm noticing S29 doesn't spec this and nearby builtins
yet. I'd like to raise the questions I encountered / stipulations I've
made. Please let me know if I'm in error or update S29 if I am not.
Regarding T
Sam Vilain wrote:
However, making it in a file in $HOME/.xxx means that the sysadmin can
set it up to be mode 400 or something like that, to ensure other users
can't access it if someone forgot to set the permissions right on the
application code (or, hopefully, configuration file).
I don't t
- optional treatment of the statements as an AST, similar in concept to
SQL::Routine, or Tangram::Expr. Death to SQL templating systems!
I suspect during this process people are going to want a lot of things
that layer on top of what we currently see as DBI.
Personally I think Tim got
At 6:14 PM +1200 7/5/05, Sam Vilain wrote:
I think I'm beginning to like it.
Allow me to suggest one or two further refinements...
my $sth1 = $dbh.compile( $sql_or_ast ); # always sans connection
$sth1.prepare(); # always with connection, even if DBD doesn't use it
$sth1.execute(); # alwa
4. All host parameters should be named (like ":foo") rather than
positional (like "?"), meeting with the SQL:2003 standard. The named
format is a lot easier to use and flexible, making programmers a lot
less error prone, more powerful, and particularly more resource
efficient when the same par
34 matches
Mail list logo
