Front page | perl.perl5.porters |
Postings from September 2011
On Fri, Sep 02, 2011 at 09:56:29AM +0200, Aristotle Pagaltzis wrote:
> * Nicholas Clark <nick@ccl4.org> [2011-08-30 18:50]:
> > I really don't want to have 2 contradictory implementations of
> > strptime() in the core. My hunch is that there will be a way to
> > achieve both desires, but I don't have any insight yet on *how*.
> > I suspect it comes down to the right interface for adding the
> > actually-useful semantics.
> >
> > We had "fun" for a while when the (newly added)
> > Socket::inet_pton() was not compatible with the inet_pton() that
> > Socket6 had provided for some years. Commit 3aca805b785501fb fixed
> > this. I don't want to repeat such "fun".
>
> The new strptime would be a function. The existing one is a method.
> I don't think this concern applies. And I don't think it applies at
> all to methods on objects too different for Liskov to apply.
You're right that it isn't going to be causing the same level of "fun" as
having two functions that behaviour differently, as we did with inet_pton().
However, the existing strftime() method is documented as
$t->strftime(FORMAT) # same as POSIX::strftime (without the overhead
# of the full POSIX extension)
ie I read that as a desire to be the same as POSIX.
For strftime() it's not trying to produce a different interface. Hence I'd
prefer to continue that to strptime(). It's documented as:
Time::Piece->strptime(STRING, FORMAT)
# see strptime man page. Creates a new
# Time::Piece object
Am I right in thinking that the information strptime() wants to return is
a) the values of what it parsed
b) what things it could parse (zero or more from seconds, minutes, hours, etc)
c) where in the string the parse failed
?
The problems being that strptime() in Time::Piece only tells you (a),
and has no way of telling you (b) or (c)?
Nicholas Clark
Thread Previous
|
Thread Next