Lukas Smith wrote:
I dont see a pressing need for an OO API and I also dont think that PHP
internal API's should one by one be moved over to an OO interface either.
IMO date is a very good example where a nice OO API is very useful -
particularly for people with advanced needs of date/timezone support.
an example:
$date_obj = date date_create();
date_timezone_set($date_obj, $timezone_obj);
vs.:
$date = new date;
$date->setTimezone($timezone_obj);
I'd definitly prefer the second way. See
http://www.zend.com/zend/week/date-timezone.txt for more examples. But
of course it's a question of personal style.
However, this is not the discussion here and has been discussed some
month ago on this list and AFAIR Derick wanted to add an OO interface later:
http://www.zend.com/zend/week/week244.php#Heading3
http://marc.theaimsgroup.com/?l=php-dev&m=112078063225818&w=2 ...
(AFAIK Pierre also implemented a non-OO interface for the date_time
extension in PECL)
What I was talking about is seperating the functions/methodes in
http://www.zend.com/zend/week/date-timezone.txt from old date()...
functions. And I can't see how the old date() could be useful if you
have a new, much more flexible API (when developing new code). And if
you don't want to live with the old date() / TZ limitations, you will be
happy that there is a solution in PHP now - I don't see a real advantage
for those few people to make it possible to use the old date() function
with the new codebase.
I'm not sure but perhaps it will be more work to argue with people (and
getting bogus bug reports) complaining about "broken" date() BC than
maintaining the old functions for some time.
But to say it again, I'm really happy about the work Derick and Pierre
invested to add better Date support to PHP. If there is an OO API for
the new code some day, I'll be very happy ;-)
best regards
Andreas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
