Re: AW: [PEAR-DEV] Do PEAR Coding-Styles make sense? (was: Re: [Zend Engine 2] Constants (was: delete construct))

Hello, Karsten Kraus wrote: > > Why? Would the code would stop being useful? > > I dare to say YES! (see below) > > > > > I am not saying that there should be no rules, I am just saying that > > some rules like function name case and fixed number of spaces for > > indentation is not necessary. > > While I really don't care about that tabs over space-thingie, i'd insist on > _ONE_ consistent naming-scheme for public functions, variables and > constants. > It makes life much easier for people like me who mainly use the PEAR-Classes > as their 'toolbox' and time-savers than to create them (of course I will > someday (i hope *g*)). > I'd don't like to have one class have methods named Class1::doThis() and > another with Class2::do_that(). But at least until PHP 5, function and variable names are case insensitive. What does it matter the case that the original author uses, when you can use whatever case you want for the function names!? > > Pushing a set of rules that adds no functionality to the code and > > require the original contributor to spend even more time to adjust code > > appearance, is highly counterproductive as many potential contributors > > will simply not do it. > > I'm not so sure... until I started using the PEAR-Classes, I was using a > complete > different coding-style (\tfunction do_this() { ... ). > I agree with you, that the PEAR-Style isn't the one and only Good ThingTM, > but it is > no problem to switch to them in most cases (I changed the function names in > my current project with among 10-30 classes in about 4 hours). You don't have a problem but other authors have. It is already a bad thing for many authors to give up full control over the development of their code, they even have to put up with some needless conventions just to have their code accepted in PEAR?! For many authors this is a sacrifice that they do not want to do because there is nothing wrong with their code! Changing indentation and name convention adds absolutely no functionality to that code. > > I think PEAR will never be as successful as for instance the PHP Classes > > Repository or even CPAN for details like this because it is not > > motivating for the original authors of the code. You have to provide so > > much effort for such a little recognition. > > I don't think so. if the PEAR Installer will be as easy to use as e.g. > ActiveState's PPM than many people will start using PEAR as their everyday > time-saver... and they'll really appreciate a consistent API/naming-scheme. I don't think the claimed benefits of only one naming schem as PEAR requires, will ever compensate the number of potential contributors that it looses. The worst part is that PEAR policy defenders will never know really how many contributors they are missing. I can provide a number for your guidance: after 2 and half years, the PHP Classes Repository has near 200 contributors. > P.S.: I personally don't like to use PHP-Classes, because I have to register > for it, but > perhaps that's just me That is a problem that some paranoid users (I am not saying you are necessarily paranoid) have regarding their privacy. They mind registering in a site like PHP Classes repository because they are afraid to be spammed, but they don't mind coming to public mailing lists like this where real spammers can grab your address easily and you can't even know about it. Anyway, the requirement of subscription is the secret of the success of the PHP Classes repository for 2 reasons: 1. Since users are required to provide valid e-mail address that provide an automatic audience to the authors that contribute to the site. All subscribers of the site automatically get in a opt-out mailing list of notifications about new classes. So when classes are uploaded all users get a notification e-mail message telling them about the new class. This provides an audience to each contributed class that is probably superior to announcing in all PHP mailing list that you know. Of course subscribers can turn off these notification messages. 2. Since users can only download after logging in, the site can track exactly who downloaded which files from the site. This provides two benefits: a) knowing which users to notify when the files of a class are updated, b) computing accurate (nobody can distort them) charts that show the classes and the authors that had more than download in the last week and all time ( http://phpclasses.UpperDesign.com/browse.html/top/ ). This works like a charm as a teaser and motivates many authors to contribute to have some real recognition, which is something that contributing to PEAR does not provide, except for eventual CVS tags that almost nobody cares about. This is a site to promote the work of the authors. If authors decided to contribute to this site it is because they don't mind users being registered to download. Those that mind, will not upload to this site. Still the site is a major success of audince. Anyway, I plan to add an option to each file to tell if it requires the user to be logged to download and let authors decide. Of course if the users are not logged, the download of files flagged to not required the user to be logged will not be accounted. Either way, authors that have uploaded their code to anywhere else, including PEAR, are more than welcome to upload to the PHP Classes repository as well (http://phpclasses.UpperDesign.com/browse.html for those that don't know it). Regards, Manuel Lemos