Re: date/timezone classes

Hello Pierre-Alain, since we now have ext/date shouldn't we rename pecl/date to something different for easier integration? And i also do not know if we aren't running into problems later if two extensions have the same name. marcus Friday, July 8, 2005, 12:44:45 PM, you wrote: > On Fri, 8 Jul 2005 09:16:29 +0200 (CEST) > derick@php.net (Derick Rethans) wrote: >> 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 do not want to extend a basic date object. This adds overheads for > nothing. pecl/date was originally designed to be integrated in php, > see: > > http://marc.theaimsgroup.com/?l=php-dev&m=104540995515576&w=2 > Integrate it in ext/date, keeping full BC with existing functions as > they do not change. When the implementations reach a stable state, > we could have been able to use it inside the current functions and > move them to ext/date. > By the way, an object with basic method/properties and more > "advanced" methods/ properties will not consume more memory, will > not add overhead to people who does not want to use an object. >> ? 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. > Even if I agree on you about a String class, you miss the point. A > 12k buffer upper cased with current functions ends with 2x 12k > buffers. > About a date/time object, these values have much more properties. > It is slighty more difficult to deal with them (non linear, > exceptions, etc.). People needs to work with ranges, arythmetics. > They also need some simple (and fast) function to get informations > other than the current properties. > Another additions are iterators, filtered iterators are a killing > feature for people having to create complex calendar applications. > a complex calendar applications is something else that the current > month calendar displayed on every single blog out there. > But words are sometimes useless, I will put my thoughts in pecl/ > date. This is a perfect place to make experiments on an usefull > APIs and get feedbacks. Once we (not only you and me but everyone > having some clue) agree on the features and the specifications, we > can then put in ext/date. > Regards, > --Pierre -- Best regards, Marcus mailto:mail@marcus-boerger.de