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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
