Re: Abstraction problem in Date class

As Lukas has mentioned before, it appears the Date class is unloved, and uncared for.. - I can see a number of things I've been wanting to use it for and it could do with a few tweeks here and there, like accepting a few more formats for setDate(). ** please speak up baba if you are back.... I think if you get time to discuss it in A'dam, the idea of introducing, some kind of policy to deal with Packages that fall into disrepear is needed. a) every 2 months - a - mailouts that you have to repond (click on url) to to say you are still willing to maintain it. - where you can come back and maintain it later, but if you are too busy there is a way to let the pear group take over patching it. b) nomitate a team of 5-10 people (or just other people with cvs access?) and allow blanket rights to commit to unmaintained packages, and apply bugfixes.. eddieajau - please file any changes as a bug report on bugs.php.net - even feature improvements. - it will ensure that something is done. Regards Alan eddieajau@iprimus.com.au wrote:

For the Date package maintainers I've found a slight flaw that prevents proper inheritance of the Date class if you are extending it (as I am to try and preserve the original Pear package as much as possible). For example, in the after method is the following line of code: if(Date::compare($this,$when) == -1) return true; If I have overloaded the compare method (which I have) then my extended class will fail. The compare method should be called like this to provide proper inheritance/overloading properties: if($this->compare($this,$when) == -1) return true; A similar, but much more extensive, problem exists if I want to create an extended Date_calc class. There are to many embedded Date_calc:xxx calls in the Date class to make this feasible and I am force to 'tweak' the Pear source (which I'd like to avoid). Could the Date_calc utility methods not be a part of the Date class itself? Regards, Andrew Eddie