On 02/18/2004 02:09 AM, Justin Patrin wrote:
However, I am more interested in legitimate users that download and try the code. This helps me test my code more intensively and iron any bugs or limitations much faster. I do not even wish or expect people to thank me. As long as they test the code and report any problems, or do not report anything because it is all right for them, that is fine for me.
I agree fully. Testing and giving back is a major reason for putting my software out there. This is why I use PEAR. There is a large group of both developers and users who actively work together to make the packages better. I also like the standardization and use of high level programming concepts, such as seperation of functionality and re-use of code.
As much as this thread was not about PEAR and PHP Classes, you seem to enjoy keep bringing that subject up. You sound like a snake oil salesman, always trying to push PEAR as the best place in the world to publish author classes, in typical attack to PHP Classes site as if it is a great threat to your existence.
The truth is that many authors will always refuse to publish their classes in PEAR for reasons that have nothing to with the PHP Classes site.
Many authors, including myself, have tried to contribute to PEAR but then there were a few individuals that were set to make it hard or even impossible to do it, usually for reasons of arguable logic. It seems that there is usually a small feud formed by a few individuals that are not interested to let other developers have a role that may put them in the shadow. With this protective attitude it is really very hard to even try to contribute.
For instance the admitance of only one coding style will always be an obstacle to motivate developers to contribute to PEAR. I even recall until today, when Andrei Zmievski said PEAR coding style was so ridiculous that made him cry. I guess that was the reason why Smarty was never contributed as a PEAR package. Curiously, I read some statistics that show that Smarty alone is a more popular PHP.net project than the whole PEAR project.
I even proposed to allow to preserve the coding style of the original contributor. The problem is that when people try to change coding styles, not only they waste a lot of time doing it right, but they may add bugs by accident where none existed. This proved to be true when Lukas Smith ported Metabase to PEAR style. Many bugs were added in code from Metabase that was working perfectly.
Forcing people to change styles is like making all right handed people start writing with the left hand to be accepted. PEAR was set to be what CPAN was to Perl but CPAN does not have such mandatory style requirements.
CPAN is a very large and useful repository. It has amazing automation and packaging as well as a great installer. However, you're missing some points. CPAN has standards as well. You muct name your module to conform with the namespaces already in ther system. You have to name your files a certai way. You are encouraged to talk about your module before submitting it. Other than that I see no written coding standards, but I highly doubt that a badly written module will last long or be used much.
You are confusing the balls here. I said that CPAN does not have strict coding style requirements. I never said it does not have rules. Even the PHP Classes has rules for classes being submitted for publishing. Coding standards is one thing more broad than just coding style.
Coding style is not a requirement because it is not possible to choose a single style as the right one, as if the others are all wrong. Many different coding styles can be used to make the readable and useful to everybody. If you coerce everybody to change into a particular style as PEAR requires, obviously many authors will be left out. Therefore, if PEAR is not more popular, you can only blame the 'smart' PEAR rulers that decided in favor of that.
One curious note, even PHP main code has coding standards. However coding style is more relaxed in practice than PEAR people demands. For instance, you will find that different parts of the PHP C source code use tabs and others use spaces for indenting.
The Perl community is old and rife with its own politics.
I would say they are more experienced. The curious part is that a PEAR zealot like yourself talking about Perl community politics is like throwning stones to your neighbour roof when your own roof is made of glass.
One of the reasons why trying to submit classes to PEAR is a major headache to many developers is precisely because of politics. The bureacracy and the number of nay-sayers is so large, that just by reading at the pear-dev mailing list archives, many authors that were considering submiting their work to PEAR, simply give up as they have better things to do than remaining in neverending discussions just to realize that their class submissions will be boycotted anyway. This is not my opinion, it is a fact that anybody can notice from the mailing list.
Actually, I'm not that surprised about the lack of standards surrounding CPAN. Perl itself is a kitchen sink language, including everything under the sun and allowing many *many* ways of doing the same thing. I myself have never been able to figure out what to do with Perl. I've used it and for big projects, but it doesn't scale well at all. But I'm digressing.
Perl syntax is cryptic because of its inheritance from shell scripting languages. However I would not underestimate the knowledge and experience of Perl developers. The fact is that many PHP people have been porting existing Perl packages, several of them have been submitted to PHP Classes site and PEAR. So, the coding styles used by Perl developers was not a problem. Therefore, your complaints about Perl sound more like fanatic attacks than valid technical criticism.
The lack of standardizaition comes with a price. If you don't enforce any kind of standards, code can very easily have bugs and, worse, be hard to understand and debug. I treat perl modules as compiled binaries (as they sometimes are) because they are almost universally hard to understand, as it most Perl.
I think you just don't know enough of Perl to comment. The fact is that there are many Perl modules that do not have a PHP counterpart.
Until PEAR people become effectively more open minded, without any hipocrisy and protectionism, PEAR will always suffer from the absence of many very qualified PHP developers, making it a shadow of what PEAR hoped to be. The reality speaks for itself. PEAR rules are not consensual nor there seems to be great interest from PEAR people to change that. It is all in their hands to change.
Good points, but you are missing something there. It is true that a rigourous standard cuts out lots of developers. Even lots of talented developers, but if you start with PEAR, it's not so hard to code for PEAR.
PEAR arrived late to the PHP scene. Therefore, I think it would have better for PEAR popularity to adapt to the existing PHP developers reality then to have PHP developers adapt to PEAR.
Unfortunately, since PEAR rules are intolerant, they decide to push unflexible rules and that discouraged many developers that not only will not use PEAR at all, but will even discourage others from using it. I am not even talking about myself. Several proeminent PHP developers have criticized and discouraged the use of PEAR. This is a fact, if you do not like it, blame it on PEAR rulers.
Even if you don't start there, the standards are still a good thing. Once you know how PEAR works, you can get any PEAR package and know how to use it, at least in simple terms. Also, keeping the same standard makes it much simpler to use multiple packages together and integrate them into your application. Take the PEAR error system, for instance. Instead of checking *every single call* for a different error sceme, I can set a single handler to deal with them. Or, if the errors are important, I know that every error that comes back will be in the same format with the same information in it.
The PEAR error system is the worst example of PEAR standards. Basically they try to emulate exceptions but in a very lame way because you can't emulate exceptions properly if you do not have built-in support in the language.
PEAR error system requires a 800 lines base class that is only there to bloat classes that used it. Basically, those 800 lines only replicate what is provided the built-in PHP functions set_error_handler and trigger_error provide. The truth is that the PEAR error handling base class is so bad that despite it used to be a requirement, several PEAR classes no longer use it. So much for standards that are only there to broken.
Again, standards are a good thing.
Sure, except when they do not get in the way of developers productivity like some of the PEAR standards.
We know that is not accurate. Many package lack of proper documentation. The truth is that writing proper documentation takes a lot of time to be viable. PEAR-Doc like documentation is as good a telegrams. Documentation is more than just a few vague words embeded in the source. It is better than nothing but unlike what you say, many PEAR packages do not come with sufficient documentation.
I disagree completely. Every PEAR package I have downloaded has sufficient documentation to start using it. Like I said before, if you can find no "documentation" all you have to do is look at the code and you're on your way. Most PEAR classes also include regression tests which are rigourously run before releasing a new package.
"A lie told often enough becomes the truth." Lenin
http://www.quotationspage.com/quotes/Lenin/
You may twist the words as you like, but the truth is that most PEAR packages do not come with real documentation. Inline PEAR-Doc comments is not documentation, it is telegram. Some people can understand with a few comments, but real documentation is made of text with many explanatory full sentences and most PEAR package do not have it, which is only natural because it takes a long time to produce real documentation and most developers do not have the time or do not enjoy producing documentation.
What you say below has no relation to the paragraphs that you quoted before this.
I don't know why you're bringing up something like this. I said nothing about your privacy policy or what you do with e-mail addresses. I didn't bash your site. I didn't say that it wasn't helpful. I am not hostile towards your site. If you look back in this thread, you will see that *YOU* have been the one making this a feud. You are the one assuming that I am attacking you. You are the one who always turns it into a bashing contest against PEAR. I have bot bashed your site or your code once until this latest e-mail, and I am not bashing your site (although I could) or the ideas behind it (which are very good and laudable). All I have done is offer an alternative and my view on why it is a good one. I have shared my view and what I see as good about PEAR in good faith and all you have done is complain. You have not given any concrete reasons for your absolute hatred of PEAR. As I see it you have given three reasons:
Are you trying to confuse people reading this thread or you are simply clueless?
As far as I can recall, you are the one that pushed PEAR in this thread.
The initial poster presented a problem. I presented a solution that is based on a class that for mere coincidence I made available in the PHP Classes.
Then, in a reaction to my message you presented a solution based on a PEAR class, that did not solve the original problem. Obviously you were not replying to the original poster but just presenting a competing solution. If you really wanted to reply to the original poster, you would reply to his message, not to my reply.
Then I told you that your solution did not solve the original problem, but then you insisted with statements that just confirmed that you did not understand the original message, which is natural because your main concern is to present a competing PEAR solution to my solution that just for a coincidence is available in the PHP Classes site.
From then on you started a PEAR propaganda speech that has nothing to do with the topic. So who is trying to attack who here?
The way I see it, if you were really concerned in providing a real solution to the original poster, you could have ignored my participation in this thread and just replied to the original poster message. Since you didn't, it is obvious to me that you have an obcessive compulsion to provide competing messages to mine, especially when I present solutions based on classes that I make available in the PHP Classes site.
If my memory does not fail, this is at least the third thread that you make this act of pushing PEAR as an alternative to classes made available in the PHP Classes site.
As to your silly claims of hatred towards PEAR, that only shows that you are completely out of the loop. You may look here to start getting a clue:
http://www.phpclasses.org/PEAR
If I really hated PEAR as you claim, would I allow publishing PEAR based classes in the PHP Classes site?
Would I list and review PEAR books in the PHP Classes site?
http://www.phpclasses.org/reviews/id/1411603613.html
The author of this book wrote me before the book it was published and asked me to list and review the book. The author told me that he wrote the book because PEAR project is not very well known and he thought that publishing this book would help PEAR. If I hated PEAR as you say, would I agree to list the book and publish a review?
Now, pay close attention to this PEAR site page.
http://pear.php.net/package/MDB
Do you know why my name is listed in this page. I did not ask to list my name. This PEAR package is based on another package that I developed and has over 12,000 lines of code. This PEAR package exists because I proposed it. If I really hated PEAR as you say, would I ever propose a PEAR package based on a large package that I developed?
Sure I criticize PEAR rules but the criticism is intentionally constructive because it is meant to open PEAR people eyes so they realize why PEAR is not reaching out and do something about it.
And now, for a bit of discussion about *your* code. This thread has been a baseless bash of PEAR for far too long.
Let's go back to documentation. Hmmm, I see code documentation at all,
If you do not see it, you must not be looking in the right places.
So far I have published 27 packages in the PHP Classes site.
http://www.phpclasses.org/mlemos
But this is just a part of my published Open Source developments. Here you may find a more complete listing:
http://freshmeat.net/~mlemos/
As you may see, these are a lot of projects. Therefore my time is limited. So, I only invest time in producing proper documentation in significant projects. Smaller projects come usually with well commented examples. Just this project manual has 280K and the tutorial more 70K.
http://www.phpclasses.org/metabase
This another popular project that is throughly documented.
http://www.phpclasses.org/formsgeneration
how interesting. Sure, there are "test" scripts which are really only examples, and those have a fair amount of comments in them, but your code itself has none. No comments for the functions. No comments for the
Don't be ridiculous. I do not think bloating source code with comments is the way to go. Other reputed developers think like me . Here is an explanation from Sterling Hughes:
http://www.edwardbear.org/serendipity/archives/1174_Comments.html
My code style is verbose. I use meaningful names for variables. You can read my code as in English. If you do not understand my PHP code, you need to study more PHP.
arguments. A maintainer of the code would have to look at the "tests" to know what the packages do. Sure, that's fine while you (the maintainer) are still here, but what if you move on? How will a new guy maintain your code? What if you're away on sabbatical and someone needs a bug
Don't be silly, I have received so many bug reports and feature request for my code that sometimes it is hard to reply to everybody that writes me. Many users write to send patches for my code. Only in your clueless imagination you can assume it is otherwise.
fix? No one else can easily step in and make a change unless they are *intimate* with your code or take the time needed to become intimate.
No one can fix any code without knowing how it works, regardless what kind of documentation it has.
That is not what I would call good documentation.
Only you are defending that comments is good documentation. Read Sterling comments so I do not have to repeat what I think.
Let's go further. Your code is much less robust than most PEAR modules I have looked at. Not only do you duplicate functionality left and right, giving a use the samer getmxrr.php file in multiple packages and making them deal with including it themselves, your functions seem strange and
Oh, man, you really did not do your home work. That script is just an interface to a DNS resolver class developed by another author so it could replace GetMXRR function under Windows or on systems where that function does not work. Since it is a small script I copy it everywhere it is needed because I do not want people to force downloading a pile a packages just to use a small script that comes with one of them.
I am not fan of nested dependencies like PEAR people seem to enjoy. Deep nested dependencies is the source of software bloat because it makes people download a pile of packages just a small functionality provided by one of the packages but it did not need all the others that it requested.
low level. I can do what you do in your tests with a few lines of code and a PEAR module. The functionality you give is nowhere near the the funtionality of the similar PEAR packages and far more confusing. Not everyone can implement everything, but in this case, I'd go with the more usable and more fully featured package.
Yes, by the time you start using all those packages that you download, you realize that PHP has wasted too much memory and time processing all the code of the packages that you used, even though you have just used just a little bit of one or few packages.
Man, you really need to learn more about software economics.
One final curious comment, while you try so hard to push PEAR and fight PHP Classes as if they are mutually exclusive, I think you do not know that several PEAR authors also come to the PHP Classes site and publish their classes their. I think they understand that exposure in two repositories is better than in just one.
Putting your code up on multiple places is great. I don't disagree with that *OR* phpclasses at all. You just seem to think that I am. Why are you so defensive? What are you afraid of?
I am just restoring your distorted view of the truth.
Just as reminder, this thread only turned into this discussion because instead of replying to the original posted, you posted a competitive reply to my own reply, just because I presented a solution that really solved the original problem that was based on a class that for mere coincidence is made available in the PHP Classes site.
I am sure that if I did not reply initially in this thread, you would even have started posting because your reply was just meant to be competitive propaganda of PEAR as alternative to my solution.
One file remark: cooperating is better than competing. If you are smart enough you will realize what you are wasting with your competitive posts.
--
Regards, Manuel Lemos
PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/
PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/
Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html
-- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
