Darren Duncan wrote:
Okay, considering that using the same name prepare() like this may
confuse some people, here is a refined solution that uses 3 methods
instead; please disregard any contrary statements that I previously made:
I think I'm beginning to like it.
Allow me to suggest one or
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
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(); #
- 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
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
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
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
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 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 the
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
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
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 thing
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 days!
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 otherwise
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
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
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
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
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 epoch. So,
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
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, Jan
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.
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
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
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
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 ... );
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
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
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 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
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
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
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 thinking: an epoch
33 matches
Mail list logo
