Alan Knowles [2006-07-12 00:38 UTC] This one's a catch-22
by the time we rename all the packages to P_* or PEAR_* PHP6 might be out with namespaces... -> in which case we end up changing them again..
I thought the original suggestion was just to Prefix the top level Packages Log/DB/Date etc. and leave the rest as-is.
P_ just seems a bit silly...
Philippe Jausions [2006-07-12 00:44 UTC] Prefixing classes with something clearly marking the class as part of the PEAR framework is definitively needed.
Besides that, "P_" is the most unsexy thing to use. Yes it's short, but frankly that would actually hurt PEAR, from a marketing prospective, and would probably also conflict with users applications. We should either use Pear_ (to make the distinction with the PEAR package and sub-class) or think about something completely different and doing so allow a rebranding of PEAR. BTW, prefixing class names would allow to go to Pear_MDB instead of Pear_MDB3, which is why maybe a rebranding could help...
Scott Mattocks [2006-07-12 12:25 UTC] Does this RFC really address a real world need? This is the first I have heard of the Date/PEAR::Date issue. And it doesn't even seem like that big of an issue. I have used PEAR in every project I have ever worked on and not once needed to use PEAR::Date (no offense to the maintainers of that lovely package). I think the phrase "which broke nearly all applications using PEAR" is a bit dramatic. Plus, the problem now can only exist if you are using an outdated version of PHP.
Would it be nice if all packages in PEAR were commonly prefixed? Sure. But doing so now will cause many more headaches than it solves. It creates a maintenance nightmare to solve an issue that does not currently exist.
This is a nice idea in theory but I don't think it translates well into practice.
P.S. Why not just create Date2 which would be PHP5 (and E_STRICT)? Non-existent problem solved.
Pierre-Alain Joye [2006-07-12 13:06 UTC] It is not only a Date problem. It is actually not a Date problem at all right now.
However we have to find a solution to use common names and reserved words as class/function names (File, Image, etc...).
Not that the prefix will be added in the next major version of a package. For example File will be renamed to pFile, P_File Pear_File or whatever_File ;)
Lukas Smith [2006-07-12 13:07 UTC] File is another one were we ran into trouble with internals. There are others too. Simply hoping that we "pollute" our namespace enough that we end up with tons of package names with a version postfix is not a solution.
Sebastian Nohn [2006-07-12 15:01 UTC] Pear_ seems fine to me. phpnamespaces.org is a private project. It is not clear if PHP6 will get namespace support: http://www.php.net/~derick/meeting-notes.html#name-spaces
If you want to know an application that broke: Eventum.
Andrei Zmievski [2006-07-12 17:06 UTC] Just to bring in a different perspective on this, PHP 6 still has a while to go and the earliest release I would expect would be a year from now. Then there is a matter of adoption which has been slow even for PHP 5. Whether PHP 6 has namespaces or not is another matter altogether.
Joshua Eichorn [2006-07-12 17:45 UTC] One way of looking at this is changing the name of every package means breaking ever current PEAR app, not just those that get unluckly with hitting a reserved word.
Now to get a small new feature or a bug fix you have to update all your code.
Prefixing new v2 php5 versions of stuff might make sense but renaming classes and doing a release doesn't unless we've actually run into a problem.
Stefan Neufeind [2006-07-12 23:03 UTC] Is somebody is (eventually) to invent a general name like "File" or "Date" again in the scope of PEAR, I agree that prefixing it with Pear_... might be a good solution. However from current use of such general terms, I think for most new packages they might be used for groups of packages (like File_DNS where File_ is only the "group").
If we are to use very common names for a new package, I guess in those cases the discussion could start to either rename it beforehand if possible or prefix it with Pear_. If there are no existing packages that we urgently need to take action with, maybe we can live another year (or maybe two refering to adoption rate that Andrei mentioned) and beg for namespace-support :-)
Ilia Alshanetsky [2006-07-13 14:48 UTC] In the best case scenario if PHP 6 were to be released this year as stable it would take many years before it would take any market share. I mean PHP 5 has been out for over a year and is barely at 10% adoption and BC changes between it and 4 are relatively minor compared to what PHP 6 will introduce. This means for the next couple of years you need to plan on PHP4/PHP5 based code and cannot rely on namespaces which may not even be part of PHP 6.
Furthermore, taking up of common names by PEAR classes is a problem waiting to happen as exemplified by "date" class and in the future needs of the language (PHP) will always trump needs of outlaying classes/libraries. This means that if the names are not changed, don't be surprised to see same names used by PHP itself causing conflicts for users/developers of affected classes.
Derick Rethans [2006-07-18 15:00 UTC] I think you need to use "Pear_" here as prefix, not a too simple two letter prefix such as P_ which can hardly be called "unique".
Derick Rethans [2006-07-18 15:01 UTC] I think you need to use "Pear_" here as prefix, not a too simple two letter prefix such as P_ which can hardly be called "unique".
Daniel Convissor [2006-08-03 13:18 UTC] Prefixing seems like a good idea. The prefix should be PEAR, not Pear, in order to allow easy migration like Greg proposed during the "PEAR::Date broken" discussion on the PHP internals mailing list:
---- PEAR/Date.php ----
class PEAR_Date {
// actual code goes here
}
---- Date.php ----
require_once 'PEAR/Date.php';
class Date extends PEAR_Date {
}
Pierre-Alain Joye [2006-08-03 13:22 UTC] a big -1 for PEAR. I'm in favour of P_ or Pear_
Also the migration idea is this insane discussion was not only pointless but wrong (even if it can work, technically ). Also I would *LOVE* to stop hear that pear was the source of this problem. The source of the problem was actually outside pear and in one and only person. Thanks.
Arnaud Limbourg [2006-08-03 13:28 UTC] Prefixing makes sense in general but at this stage of the game we have to consider the rewards of asking of everybody to update their code. I'm not sure it is worth it.
One solution could be to have new packages being prefixed with "PEAR_" or make sure they are not using any (potential) reserved words.
Markus Wolff [2006-08-03 13:39 UTC] I second Arnaud's opinion - prefix all new packages (+1 for PEAR_ btw.), leave existing packages as they are.
The inevitable move to PHP5 will trigger the creation of new major package versions for existing packages anyway, so that will be a good opportunity to introdue the prefix as well. It does not make sense to force existing packages to adapt and destroy backwards compatibility when it is not really neccessary.
Amir Mohammad Saied [2006-08-03 14:32 UTC] +1 for Pear_, And prefix for next major version of a package.
(IMO Pear isn't an acronym anymore, just a name)
Craig Constantine [2006-08-03 14:47 UTC] I'm for: Prefix "Pear_" for new packages (much nicer than "DB2", etc!) as they appear.
I'm against: Our recommending renaming packages causing BCbreak. Deal with problems like PEAR::Date/PHP's Date as they come up.
|
