Re: RFC for Adding __toString to DateTime
| From: | Derick Rethans | Date: | Sun, 02 Sep 2012 11:35:06 +0000 |
| Subject: | Re: RFC for Adding __toString to DateTime | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-62667@lists.php.net to get a copy of this message | ||
On Sun, 2 Sep 2012, Will Fitch wrote:
> On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
>
> > > I would like to officially introduce an RFC with a patch to
> > > implement __toString to DateTime. This is a commonly requested
> > > feature that goes unanswered mostly because of the inability to
> > > agree on a default pattern.
> >
> > This must indicate there's actually no default pattern that is
> > "default" for everyone. Which suggests maybe we shouldn't have
> > default string conversion there? After all, nothing prevents one
> > from having:
> >
> > class MyDateTime extends DateTime {
> > public function __toString() {
> > return $this->format(/* whatever my favorite format is */);
> > }
> > }
> >
> > I'm not sure introducing special state to DateTime for it is the
> > best way to handle it. Also, most applications would have common
> > date format - which means since the state is per DateTime object,
> > they'd have to watch that every object produced would have this
> > property set. I think it'd be easier to just use DateTime->format()
> > - this way you know what is produced and it is clear for whoever is
> > reading the code too.
> >
>
> This has been on my mind as well. I've considered that maybe an INI
> wide setting would be beneficial here.
We should absolutely NOT add ini settings for this. They make things
unportable.
> In fact, there are many places
> within applications I've worked on where the format for many DateTime
> objects are the same. What are your thoughts on that?
Inherit it in userland!
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine