AW: [PHP-WIN] Re: Emailing via mail(), secondary servers

To both of you crusaders, first of all you are by far off topic now, so please relocate to a suitable list. And as I don't see this quarrel get to any kind of "solution" I would like to add my very personal unwanted comment: Besides and above any substantial point in any of your proceedings it may be valuable to think about how _the other side_ (with their respective prereqisites) may be able to _accept_ the point one wants to make in the first place, not to speak about an agreement (Hint: no one likes himself or any of his ideas to be called silly or the like ...). Try to think about what exactly you want to achieve _yourself_ before you start reasoning about the other's motivations. Happy arguments, -- Sven > -----Ursprüngliche Nachricht----- > Von: Manuel Lemos [SMTP:mlemos@acm.org] > Gesendet am: Donnerstag, 19. Februar 2004 01:00 > An: php-windows@lists.php.net > Betreff: Re: [PHP-WIN] Re: Emailing via mail(), secondary servers > > Hello, > > 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