On 02/17/2004 07:26 PM, 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. The Perl community is old and rife with its own politics.
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.
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.
PHP, on the other hand, is much easier to standardize, especially if we start now before we're as bug as Perl. PEAR in particular I find easy to use. There is *always* some kind of documentation for a decently developed package.
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.
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.
Again, standards are a good thing.
The documentation is also very important. Nearly every bit of code in PEAR packages is documented. If no "Documentation" is on the site, you can still check the code itself to find instructions and even usage and examples.
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.
Obviously, the "knowledge s*ckers" will not provide any valuable feedback. Actually some of them even come in public just to b*tch that I require them to login to download my stuff. Some even threat to download similar packages from some other repository, as if I care. The world does not revolve around any individual alone, even less KS.
If that requirement of login detracts some KS from even accessing the site, that is just perfect for me. That is not the main reason to keep that requirement for my classes but it is one reason more.
I can justify spending time and effort to retribute the feedback that legitimate users provide. As for KS, sorry, they are not helping me at all, so I can't justify even to worry about the usual b*tching or threatning to use the TV of some other neighbour. ;-)
Instead of making harder for legitimate users to use your software, maybe you should think about why people are "knowledge sucking" instead of using your class.
When I say legitimate users, I am talking about those that do not have a problem to become subscribers of the site and download the package made available in the site by the authors.
In general I observed that some people show an hostile atitude towards the site because they do not want to trust that when they subscribe they will benefit from a whole set of services for free. Instead, some assume that their e-mail addresses will be sold to spammers and other conspiration theories that have no foundation in any facts.
Since I developed and manage this site, I can tell you that those objections are absurd. As you may imagine I cannot simpathize with people that on one side want my software but at the same time do not trust me.
Everybody is free to disagree with me but I do not consider potential legitimate users all those that do not consider my site trustworthy. I can certainly live well without those users. As I said, if all they wanted was to s*ck my knowlegde, and so would not provide any valuable feedback in any circunstances, I am sure I am not loosing nothing. I certainly do not develop free software for people with hostile atitudes.
On the other hand, the site is open to anybody. Any author has a chance and is free to contribute with any classes they may have. There is no feud raising opposition based on arguable requirements to the classes that may or not be published. This is democracy applied to software sharing. This is why about 700 authors have so far contributed with about 1250 classes.
Instead of boycotting the classes before they are published, the site adopts a natural selection method to outstand which are the most appreciated solutions for each topic. That works by letting users rate classes on important technical aspects.
The best rated classes will feature in the site top charts. The authors of the best rated classes may win prizes every month. The users that make the most accurate ratings may also win prizes every month. That is so you can see what the users that refuse to subscribe for whatever reasons are loosing.
Users that become subscribers benefit of useful services, unless they do not want them, like getting automatic notifications by e-mail about new classes or updates on classes that they previously downloaded. This not only makes it possible to provide a large immediate audience to the authors that publish in the PHP Classes site, but also keep the users quickly upto date about class updates that may include great new features or even important security fixes.
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:
1) The enforced style
Have you even looked at the PEAR standards? They're relatively simple. There are 11 points, most of which are very easy to understand and use. True, there are some unwritten conditions in there for conrtibuted code, but they are also there for ease of use.
It is not as much an enforced style as a coding standard. I talked about standardization before, so I won't reiterate here. The "style" is not an arbitrary collection of rules. It is a standard that is used to promote cross-compatibility and easy usage of all code by any developer. Like any standard, it takes time to get used to, but once you're used to it you can move much faster than if you have to constantly re-learn how each piece of code works.
2) The strictness for getting code into PEAR
See above. Standardization is a good thing. While it is useful to have non-standard code, it should not be a part of PEAR itself. Other sites, such as yours, are a good place for people to get their feet wet, although learning good coding practices right from the start is a tremendous help.
3) The amount of code
You and others have repeatedly complained about all the code you have to include to get one thing to work. Sure, to use a PEAR package you almost always have to include PEAR.php and usually a few other files depending on what you're using, but what do you get for that extra code?
a) Standardization
b) Seperation of functionality
This allows someone to easily use, say, socket connection code (Net::Socket) in another app rather than reproducing the same code in multiple classes. It also allows developers to easily build upon others' work.
c) More functionality
You can use HTTP_Client as what it is, a client, or you can use the underlying HTTP_Request to make a single request, or you can use Net_Socket to make a simple network connection, or you can use Net_URL to parse URLs. The underlying code is all there and easily usable without having to include HTTP_Client if you don't need it.
Other than those three points, you have said nothing of substance except to complain about why people won't come to your site. What do you find so offensive about PEAR? What's wrong with its coding standards? Give us some concrete reasons; make this a discussion. Discussions allow us to improve the standards.
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, 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 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 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.
That is not what I would call good documentation.
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 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.
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?
-- paperCrane <Justin Patrin>
-- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
