Re: date/timezone classes
| From: | Derick Rethans | Date: | Fri, 08 Jul 2005 07:16:29 +0000 |
| Subject: | Re: date/timezone classes | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-17188@lists.php.net to get a copy of this message | ||
On Thu, 7 Jul 2005, Andi Gutmans wrote:
> If you're just wrapping the date type with a class, I don't see why it
> shouldn't be a resource. It'd give you the same thing but would be easier to
> implement (unless I'm missing something).
Objects are not harder to implement, I found it actually more straight
forward. Besides that, making it an object allows other people to extend
it, something that Pierre wants for his pecl/date.
> I realize you personally aren't fond of OO but it actually would work very
> nicely with a Date class. I'm not talking about OO as in over-architecting and
> having a huge hierarchy but just having easy to use methods on the
> Date/TimeZone classes (one simple level).
>
> It would look the following:
>
> $timeZone->getName();
> vs.
> date_timezone_get($date);
Those are not equivalent.
> $date->getOffset();
> vs.
> date_offset_get($date);
>
> Personally, unrelated to OO I think it's a nicer and cleaner way of exposing
> such an API. It would also make it easier for some of the other new extensions
> like SimpleXML, SOAP, PDO , etc. to take advantage of it when exposing data
> types.
? The way how they expose datatypes doesn't really differ. It's just
that *currently* I've no plans to add fancy methodnames. All other
functions on standard datatypes work with functions. This falls IMO in
the same category as not wanting a full blown String class in the core
of PHP.
Derick