Darren Duncan wrote on 2009 Feb 17:
Timothy S. Nelson wrote:
Agreed, and that's kinda what I'm doing. But I still think
there's room for improvement. I'll try and design an API that does
what DateTime does, but:
Talking about dates and times, I have some suggestions.
Second of all, I t
Dates starting at midnight is fine, but I agree that a Date shouldn't
automatically coerce into midnight on that date. If it's going to
autocoerce at all, I'd recommend noon instead, but better to force the
programmer to pick what they mean.
On Fri, Feb 20, 2009 at 2:32 AM, David Green wrote:
>
On 2009-Feb-19, at 4:39 pm, Martin Kealey wrote:
2. "Date isa Instant" works sensibly: anywhere that expects an
Instant, you
can give it a Date. (Assuming we all agree that dates start at
midnight, but
then we *are* talking specifically Gregorian dates.)
I don't like dates just starting at
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
> On Thu, 19 Feb 2009, Martin D Kealey wrote:
> > Rather, let's have immutable time "values", and methods which return other
> > "values" where various computations (*1) have been applied. Provide
> > constructors which take the Y/M/D/h/m/s/dst_now/dst_
Just to clear up ahead of time, the consensus both here and on IRC
seemed to be that in the core, we put a basic Temporal::Instant object that
about powerful enough to deal with:
- localtime/gmtime functionality
- ctime, mtime, etc, in stat()
- nanoseconds or whatever needed f
On Wed, 18 Feb 2009, Dave Rolsky wrote:
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
Agreed, and that's kinda what I'm doing. But I still think there's
room for improvement. I'll try and design an API that does what DateTime
does, but:
1. Uses more variables, of which I expect the g
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
Agreed, and that's kinda what I'm doing. But I still think there's
room for improvement. I'll try and design an API that does what DateTime
does, but:
1. Uses more variables, of which I expect the getters and setters to be
overridde
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
> I'll try and design an API that does what DateTime does, but:
> 1. Uses more variables, of which I expect the getters and setters to be
> overridden.
Please let's NOT have setters on "time" objects. They're a source of subtle
bugs in such client co
On Wed, 18 Feb 2009, Richard Hainsworth wrote:
For what you want, I would think, you need
@files = grep { :f } $dir.contents; # note the adverbial form, which is
mentioned in one of the other specs.
Yup, thanks.
By analogy there would be
@subdirectories = grep { :d } $dir.contents;
On Wed, 18 Feb 2009, Mark J. Reed wrote:
On Wed, Feb 18, 2009 at 6:36 AM, Richard Hainsworth
wrote:
What needs to be abstracted so that a perl6 program can know that a
Writeable may not be able to accept data (eg., because the file system is
full)?
I don't understand the question. To be a W
On Wed, Feb 18, 2009 at 6:36 AM, Richard Hainsworth
wrote:
> What needs to be abstracted so that a perl6 program can know that a
> Writeable may not be able to accept data (eg., because the file system is
> full)?
I don't understand the question. To be a Writable, an object must
have a mechanism
Actually, it seems to me that we do agree fundamentally, although using
different terminology.
And like I said in an earlier email, I do like/agree with the way you
are taking the Spec.
Also, it seems to me a re-ordering of the material in the Specs would
make more sense.
On our disagreeme
Em Ter, 2009-02-17 às 22:38 +1100, Timothy S. Nelson escreveu:
> My third thought is that it would be very useful also to have
> date/time objects that integrate well with eg. ctime, mtime, and the like;
> I'd
> start with Time::Piece as a model.
> http://search.cpan.org/dist/Time-Piece/Pi
Timothy S. Nelson wrote:
On Tue, 17 Feb 2009, Richard Hainsworth wrote:
Timothy S. Nelson wrote:
be specifying our files; it's prettier than File::Spec :), and
unified.
Anyway, HTH,
I like all the default suggestions.
Not sure whether this means you completely agree with me, o
* Timothy S. Nelson (wayl...@wayland.id.au) [090218 03:08]:
> On Tue, 17 Feb 2009, Richard Hainsworth wrote:
> >Moreover, if perl6 distinguishes between a location and a file, then the
> >spec can distinguish between a .children() method that provides a list of
> >child locations (viz., sub-direc
Timothy S. Nelson wrote:
On Tue, 17 Feb 2009, Darren Duncan wrote:
Second of all, I think a more generic term than DateTime should be
used to name an object that represents an instant in time; for example
I suggest calling it "Instant". The name "Instant" fits in a lot
better in the company o
On Tue, 17 Feb 2009, Darren Duncan wrote:
Talking about dates and times, I have some suggestions.
First of all, I don't think that most DateTime stuff belongs in IO. The
class definitions to represent a date or time or duration etc value, as well
as operators to convert date formats etc or a
Timothy S. Nelson wrote:
Conceptually, I agree. But there are places that Time::Piece assumes
time is a sane thing, and it just isn't. Date::Time has a less DWIM
interface, but is much more correct in the face of general human
nuttiness on this topic (especially with regard to durations and
tim
On Tue, 17 Feb 2009, Geoffrey Broadwell wrote:
On Tue, 2009-02-17 at 22:38 +1100, Timothy S. Nelson wrote:
My third thought is that it would be very useful also to have
date/time objects that integrate well with eg. ctime, mtime, and the like; I'd
start with Time::Piece as a model.
htt
On Tue, 17 Feb 2009, Richard Hainsworth wrote:
Timothy S. Nelson wrote:
Hi all. I know we usually run on forgiveness instead of permission,
but I'm suggesting a big change (or extension, anyway), so I wanted to run
the ideas by you all before I put the effort in. If I don't get feedback,
On Tue, 2009-02-17 at 22:38 +1100, Timothy S. Nelson wrote:
> My third thought is that it would be very useful also to have
> date/time objects that integrate well with eg. ctime, mtime, and the like;
> I'd
> start with Time::Piece as a model.
>
> http://search.cpan.org/dist/Time-Piece/Pi
Timothy S. Nelson wrote:
Hi all. I know we usually run on forgiveness instead of
permission, but I'm suggesting a big change (or extension, anyway), so
I wanted to run the ideas by you all before I put the effort in. If I
don't get feedback, I'll just make the changes.
The first thi
Hi all. I know we usually run on forgiveness instead of permission,
but I'm suggesting a big change (or extension, anyway), so I wanted to run the
ideas by you all before I put the effort in. If I don't get feedback, I'll
just make the changes.
The first thing I wanted to suggest was that
23 matches
Mail list logo
