RE: [PEAR-DEV] php5 packages - interfaces

I think Joe has raised and extremely important question: Will PEAR be forever based on PHP4 or will we eventually start seeing PHP5 specific classes taking advantage of the PHP5 enhancements? (I know we already have PHPUnit2 but that kind of lives in it's own world anyways). Certainly maintaining compatibility with PHP4 is important in the short term but is it unreasonable to target say PHP5.2 as shipping with a set of PEAR5 classes? If we do accept the notion that more and more PEAR classes will require PHP5 then it might be reasonable to start planning for them. 1. Interfaces - per Joe's email. 2. Exceptions Big thread on the internals list on using exceptions for error handling. It's not obvious how they should be used in the PEAR context. 3. Iterators 4. Class constants, overloads, autoload,abstracts,constructors,destructors,cloning - all kinds of fun 5. Naming convention IMHO, it would be useful to rename classes to indicate they are PHP5 only. The main reason being that allowing both the old class and the new class to be used in the same script at the same time might ease migration and testing efforts. My own humble suggestion would be to just stick the number 5 after the category i.e. XML5_Parser. -----Original Message----- From: Lukas Smith [mailto:smith@backendmedia.com] Sent: Friday, April 16, 2004 11:31 AM To: Joe Stump Cc: pear-dev@lists.php.net Subject: Re: [PEAR-DEV] php5 packages - interfaces Joe Stump wrote: > OK, the only questions I have now are ... > > 1.) Do we have an outlined upgrade path for package maintainers to > follow for the php4 -> php5 transition? err? not specifically but there are guidelines on how to deal with BC breaks (and making your package depend on PHP5 after previously working with PHP4 certainly is a BC break). Beyond that the QA team tries to help with making packages work both in PHP4 and PHP5 Anyways interfaces are nothing more than a "contract" and starting with PHP5 we now have a way to enforce these "contracts" with technical means. So to me interfaces or defining interfaces is not really a PHP5 thing. However I do think that there is benefit in using the PHP5 interface syntax to define interfaces for PEAR. These could then be used both for all packages in PEAR. > 2.) Should I write up a PEPr proposal for a interface package? (maybe > one outlining that other packages with factory methods should create > their own as well? Kind of an RFC of sorts ...) I am not sure if PEPr is the best place to start your efforts. I think that your best bet in getting something like this into PEAR is to collaborate with as many people on pear-dev as possible. Well this can probably be done with PEPr actually. All I am saying is that this task will take a lot of compromising. Actually this is more or less what people have been asking/opposing for a while: a regulation (guideline) on method names regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07 -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php