Re: Re: [metabase-dev] MDB news

From: Date: Tue, 17 Sep 2002 08:09:36 +0000
Subject: Re: Re: [metabase-dev] MDB news
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-9098@lists.php.net to get a copy of this message
Hello, On 09/16/2002 04:45 AM, Björn Schotte wrote:
I liked the discussion on PHP-DEV about SOAP/Web Services some months ago. I liked your postings, but only one part of them: the fact that you see SOAP/web services as an important thing. Nevertheless I didn't like the tone of your mails.)
Yes, the tone is often use as an excuse to refute what I propose.
No. Perhaps you need some lessons in rhetorics, diplomacy and "general rules of constructive discussions".
Never mind. You do not seem to try to understand why I am the way I am and I really do not have to justify myself to you or anybody.
have decided on their own to exclude themselves from participating in it. It is their choice, so it is their problem.
Yep. And the same is for those developers who don't like the PEAR coding standard and so they exclude themselves from participating in it. It is their choice, so it is their problem.
No, it is not just their problem, is a problem of the whole PHP community. The PHP Classes site is an initiative of an individual that is not sanctioned by the PHP Group and it is not assumed to become the
And because PEAR is "sanctioned by the PHP Group" or comes officially with the PHP distribution, there's a huge liability of PEAR and its developers to produce code/packages with a good *quality* in mind.
It is very naive of you to think that a single code standard assures any quality. If you talked to me about quality assurance procedures like tests that prove that the API work as documented I would agree. As for style, any package may have many bugs and design flaws regardless of the style they use. Style is about looks, not brains.
You are only talking about *quantity*. On the one hand it is right (i.e. to be accepted you need many packages), on the other hand not because PEAR should be of a good quality. And coding standards are one point where good quality counts.
You need to learn a little more about statistics. Sure if the rules are loosen, people with different levels of programming skills wil contribute. OTOH, you are not stopping better qualified authors from contributing. That is the problem of PEAR. A lot of the qualified developers do not contribute because PEAR rules make it unviable.
assumed.PEAR will hardly become such standard library by circunstancially excluding many qualified developers from contributing.
A qualified developer is able to change the coding style. And, as somebody told in another mail, there seems to be code formatting tools where you can easily change the style (haven't tried it yet).
If you are right handed, would you think it would be fair if your publisher demanded that you to start writing with the left hand? That is how developers that do not contribute feel. There are more reasons.
Either you did not notice the
... I didn't have the time to answer you. And as told in another
That sounds pretty much as if you are not interested.
Persecution mania, part II?
The fact is that you did not answer. If you would really be interested you would have answered soon or later. Sometimes I may not pay attention, but is unfortunate of you to try to make me dumb.
The opportunity is for a fair banner exchange like it was accepted by the PHP-CON marketing people. So, if you are interested, just reply to me privately on this subject.
Just ask Frank Stepan, he's the one who decides that.
I asked already. I hope that if he is not interested for whatever reasons he may have, at least be straight and tell me. That would be a decent posture.
I refer to the tone. If somebody wants to be heard by somebody, he has to adapt to a factual tone.
The tone is intentionally meant to bring the attention of people that otherwise would avoid the subject as have done before.
As you can see (and you should have learned about it in the past), this doesn't work.
You have no idea how you are so mistaken.
My point is to provide feedback about the way people are seeing PEAR. If you think that is just me, go and read the comp.lang.php thread about why people do not want to use PEAR. I intentionally excluded myself from
I have read this thread and loughed out loudly.
I said the thread, not just a single message.
Manuel, please read my lips: I HAVE READ THE WHOLE THREAD.
I never doubted that. The issue is that from a whole thread you just comment one message just to make fun of some user that you disagree with. Many important things were said in that thread that you decided to ignore or minimize. That way you will not learn and evolve.
Anyway, if avoid trying to understand why a few users do not use PEAR,
I don't avoid it.
Yeah, a real professional user. He doesn't have "time" to dig into the _use_ of the PEAR classes (on the other side, you need to bring time with you if you want to *commit* PEAR classes, but this user wanted to _use_ PEAR classes).
AFAIK, this user never meant to be a contributor. He was explaining why he did not want to become a user.
Yep. But this is not a reason why PEAR folks should be responsible for that.
You need to pay more attention. If the user got the wrong idea about PEAR, that can only because PEAR people did not care to assure that he gets the right idea of what PEAR is.
Also, he obviously hasn't seen some bigger OO projects/frameworks where one class relies to another, i.e. as PHPLib Auth class does (relying on PHPLIB::Session, PHPLIB::DB and PHPLIB:CT_* class)
Moderate dependence is understandable. However, forcing a dependendance on fat base classes like it is required in PEAR is often inappropriate
Which fat base classes do you mean? And what does "fat" in your eyes mean?
I am talking about PEAR base classes, what else? Since they are required to be the base class for the other PEAR classes, they all add a bunch of variables and functions to all derived classes. I don't know if you are aware, but PHP objects are indeed made of associative arrays. This means that every time you create an object, you need to initialize the whole associative array adding their entries one by one. Also to access a object class member, PHP needs to do associative array lookup using the member name as key. As you probably may understand by now this adds a needless overhead to object initialization and access that gets worse as the number of variables and functions increases. So, adding fat base classes is generatlly not a good idea, especially in PHP. Too bad most people are not aware or else they would probably rethink their class design.
The next professional user. Why does he think that he's the navel of the world and everything else has to follow _his_ style? Reality is bottom-up: if _you want to use_ another thing, you have to adapt to the thing's style, and not the other way round.
That is why he and many other people are not using PEAR.
Yep. But don't you see that this is a *WRONG* attitude? If you WANT TO USE other things, YOU have to adapt to their styles.
You are not getting it. He does not want to adapt, so he will not use it. It may be wrong from your point of view, but he his the one to decide that is worthy to adapt.
That's the same like on social groups: if you have a group A and an outsider B who wants to be part of group A, what does he have to do? Right, he has to adapt to the rules the group A has chosen. If he doesn't want to adapt, he remains an outsider. Same for countries: if you want to live here in Germany, you have to adapt to local rules. If not, you're an outsider. The same counts for every other country in the world.
Your example is very good to remind you that when the European Union was formed, the inhabitants of the countries were not required to use only one idiom. They just respected the original idiom. This is more like what I proposed. Respect the style of the original contributor if he would like that. Otherwise move to PEAR style if the original contributor would not mind. This is community spirit. You will have an hard time coercing contributors that are not willing to change their style. The loss is for the community and the contributors that are not willing to change. You seem to lack of the necessary tolerance to see that.
Obviously he doesn't know that PHP already entered the enterprise market.
PHP has little credibility to enter in the entreprise market like other
Since I'm working in the enterprise market, be sure: PHP already entered it.
Bjorn you do not need to sell PHP to me or anybody here. The point is that PHP lacks of serious tools for developing enteprise applications that are granted to other languages.
languages did.
That's right, and there's much work to do, but that doesn't depend on some fluffy coding styles of PEAR.
Sure, it depends on motivating as many qualified people as possible to contribute. Forcing everybody to one style only is counterproductive regarding that goal.
like those things), but it's not true thinking using these words will change anything in the heads of the developers.
I would not be that sure.
Then prove it.
I won't bother to give examples, but you may want to try to pay more attention to what happens after many heated discussions that I participated.
Prove the above or shut up.
Oh, man, you seem to enjoy making me write long messages. Ok, just one example of one heated discussion a long time ago. For the other discussions, draw your own conclusions. Once upon a time, in the days of version 3, PHP was very unstable the more extensions you added to it, the more it would crash Web server processes. This was driving me crazy and after I enabled debug information I could trace the crashes to misuse of memory allocations. Having been a C programmer since the early 90's I knew very well some very effective techniques on how to trap misuse of memory allocations, like using memory walls to very memory space overrun or underrun, verification of memory allocation addresses, etc... So I went to PHP-DEV and proposed all this. As usual Rasmus was in a bad humour and was refusing every thing I said with excuses that he had no use for that and I should do in only on my PHP copy, and that it would add runtime over head despite I suggested to activate that only when PHP is compiled in debug mode and all the silly excuses that Rasmus could remember. The funny part, is that it did not took a couple of days until Zeev jumped in adding some code to do exactly what I proposed. That was really ridiculous but it paid to put with all the opposition that Rasmus as making with those silly excuses. Anyway, that was just one episode. Many other episodes followed proving probably in not so obvious ways that certain heated discussions are not in vain. The point that you should get is that for as much strong and vocal opposition that I often get in these discussions, the fact is there is always people that is actually reading with attention and they see that after all I am bringing some good points and all that is for the best for PHP. I am not saying that the same people agree with me all the times. What I am saying is that often it leads to a positive effect, usually after some time when the dust rests, not just after a couple of days like the episode above.
I only said that I have the *impression* that you *tend* to see phpclasses as the navel of the world. It is not a problem for me, since I can ignore it and I or my dayly life don't suffer from it. But the impression stands out.
Bjorn, you were the one that brought the PHP Classes site to this thread. You do not seem to ignore it and it seems that you are making a big deal out of it as if that is a problem for you.
Buahahahahahaahhahaah. Persecution mania, part III? (Stab I - III) I only touched the discussion in one point to "PHP classes". The discussion itself is not concentrated on "PHP classes".
Nor I meant it to be. You are the one that brought it up and seems to be interested to continue.
I wish people stop having sick feelings against the site that after all is a good thing for the PHP community. However, it seems that some people keep bringing the site to the discussions that I am envolved some times with the intention to attack the things that I do.
Persecution mania, part IV?
Yep, ask the Sterling Hughes, Derick Rethans, Sebastian Bergmann, James Cox, etc... (all @php.net badgers) they are the ones that I recall better of expressing sick envy and get very disturbed when I try to help somebody in PHP mailing lists and newsgroups pointing them to classes in the PHP Classes site that may solve the users problems. Do you really want to keep bringing the issue further? It is not helping anybody here.
I don't think so. Also you may not forget that the "PEAR el3333333t" is very helpful. I can remember Martin Jansen helping me commiting the PEARifyed PHPLIB Template class (thanks Martin!) some months ago. So I don't think the "PEAR el3333333t" is trying to keep people out.
That doesn't avoid the fact that you had to spend time starting to PEARify the code yourself.
Yep. I chose to invest time (15 minutes) to read the coding standards and adapt it. It was *my* choice to participate in PEAR.
Small classes of course. If you are enjoying so much PEARifying PHP classes, try helping Lukas PEARifying the rest of the 12,000 lines that make the Metabase drivers code. Oh, wait, I read the other message, you also seem to have a problem with Metabase!
continue productive using the PEAR style. Like I said, if you are right-handed, it would be like making you write with left hand from now on.
Then just don't contribute. Nobody forces you to do that. If you want to contribute, you know what you have to do (invest 15 minutes to read and understand the coding styles and then some more minutes to hours to adapt your existing code that you want to contribute). If that's too much work for you, that's okay.
If my classes had only 100 lines of actual code, 15 minutes would not be a problem.
And, I think you can't compare PHP classes and PEAR: PHP classes is open for everything (like CPAN and perhaps it lacks of a medium quality like CPAN does because it accepts everything in (even bad) every coding style).
You are very funny. You keep bringing the PHPClasses vs. PEAR issue, and then you claim that I have a persecution mania. Is it my impression or you really want to keep teasing me?
PEAR is open for everything, but it wants to assure that the quality of the code will remain on one level. That's the main big difference.
Only on your mind quality is measured by style.
You make it sound as if developers have the duty to conform to rules that they are not paid to work by, as if they are obligated to contribute. Since they are not obligated to contribute at all, obviously you will see a lot of qualified developers refusing to contribute.
So what? Is this the problem of PEAR? No.
It is a problem of the PHP community and its future.
Why?
PEAR is the only repository sanctioned by the PHP group. If PEAR does not evolve with the best contributions that could be made, be sure that the whole PHP community looses opportunities.
1.) It's always easy to criticise things _after_ they were created. 2.) It's more productive (and it's harder so that may be the reason why people like you are preferring 1.) to criticise things during the _process of creation_.
I suggested to be more flexible allowing the code to preserve the original style of the contributor if he is not willing to convert. I was not heard.
See above: if PEAR opened it's coding rules to be more flexible (how much?), I doubt the quality of the code would be the same and on one level.
If you believe that looks are more important than brains that should make sense to you.
The democratic process was the discussion on this list. In my opinion, having Usenet rules (for example) like RfD/CfV would be overblown.
There was no vote, just opinions exchanged.
Yes, as I said, having such votes would be overblown.
Why? Are you afraid that a democratic vote process actually demonstrates that the community does not agree with the rules set by the PEAR elite?
I can repeat myself again: everyone who decides not to contribute to PEAR has made a choice. That's okay. But that's the problem of the developer and not for PEAR. If some rules have to be re-thought, I trust the "PEAR el3333333t" will do that.
The subject was brought over and over again and the PEAR elite remains inflexible.
Who brought the subject over and (if it was you) in which tone?
Always the tone excuse to avoid the subject...
I think the same would be okay for phpclasses, wouldn't it? So if somebody would refuse to contribute to phpclasses for reason X and Y, you would also say "That's okay. You made a choice not contributing to phpclasses. It's your problem, not the problem of phpclasses", wouldn't you?
Sure, but the difference is that the site does not require anybody to change their classes to contribute.
Maybe, but that's not the point. The point is that you would behave the same.
You have no idea of the PHP Classes site approval process. It has rules that are very flexible. 17% of the class entries that were created were refused, some times because the user actually did not post any code, just put up some link to some other site, or because what he posted was just a script that is not really made of any classes. I don't have a problem refusing such class entries. I usually give the authors a change to correct their contributions if they are willing to have their code approved. As you may understand, the entries that are refused are because their are not consistent with the site name and goals which is to be a repository of PHP Classes made freely available in the site as the site users expect. There are no rules like avoiding non-conforming a single style or classes of similar purposes. I always try to be fair and give everybody an equal chance to participate. That is the way I see that a community of users of voluntarily contributed components should work. But that is what I decided for this site that is not competing with PEAR as it is not meant to be the same thing but rather an alternative for exchanging free PHP components that I have a great pleasure to let anybody in. Everybody is equal. Nobody should be more equal than the others. -- Regards, Manuel Lemos

« previous php.pear.dev (#9098) next »