1. Interfaces - per Joe's email.
Have a fundimental problem in a scripting language (eg. more files to load..+++ extra memory +++ more things to parse == slower) - One of the general concerns people have about PEAR ( look at the ADODB vs PEAR::DB speed issue) is the speed and size of some of it's packages. we should be careful, especially where speed & preformance is an issue, not to bloat simple tasks with too many files..
It may be worth waiting to see if PHP5.1 introduces some kind of way to ignore interface errors
:: eg. include_interface '.....'; - so they are not loaded on production machines..
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.
Again I dont know if they will go down the road of Soft Exceptions (emit/warn, but dont stop execution) / Hard Exceptions (emit+stop execution), and remove the layered tier down catching.... (forcing you to only catch exeptions where they are thrown, and manually throw another one to tier it down) - At present I'm not tempted to use them at all. - as I think they will tend to introduce more problems than they solve..
3. Iterators
Probably worth using :)
4. Class constants, overloads,
autoload,abstracts,constructors,destructors,cloning - all kinds of fun
DataObjects already has cloning, and overload support for PHP4&5 - overload is a royal pain in the ass, as the API changed..
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.
the packager already has
requires php => 5 in it.. (although there's not much to stop you trying to use it with php4 once it's installed..)
I should think it will be pretty obvoius that something is not php4 compatible, as soon as you use it..
Regards
Alan
-----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