Re: Re: [metabase-dev] MDB news

Hello, On 09/17/2002 06:08 AM, Derick Rethans wrote:

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.

But I don't think you can deny that a general coding and structure style throughout packages in a library helps getting a better overview at

Trust me, the great majority of the users of PEAR will not even look at the code to judge it for the style.

quality. Instead of getting accustomed to like 10 styles you only need to 'learn' one.

Sure, but the truth is that PEAR style is not the only one nor the one that is right. Other people have their one styles and use them consistently. The quality of their code is not worse just because they do not use PEAR style. Believe me that many qualified developers will not look at PEAR seriously if you keep pushing that only PEAR style is right and therefore the only one acceptable.

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.

In comparison to the huge pile of packages on the PHP Classes site I think it is not that bad to have a somewhat higher burden. Any qualified

That is because you are not aware of what you miss from the really qualified developers that contribute. Trust me some very developers contribute with amazing classes that are quite surprising. In the other day I saw a class that would convert UML diagrams to database schemas and also from database schemas to UML diagrams. This is just to make you aware of the potential that PEAR misses. I am also aware that the PHP Classes site does not even more sophisticated packages because I did not had the time to improve the package upload system to make it easier for more complex packages to be contributed. That is matter of time until I do so.

user should be able to change his style/structure to PEAR's within an hour (depending on size of course)... (otherwise I wouldn't call it a qualified author).

You are intolerant.

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.

Do you have a better idea?

Sure. How about doing like lower level languages like C/C++ that put class members in a linear array? I know that would require non-trivial changes to the current PHP object model, but at least it would get rid of most of the overhead and memory waste.

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.

sure, blame Andi for being incapable..

I was not thinking of Andi or whover was concerned with the PHP object model. I was talking about people that design PHP classes.

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.

Yup, it's his problem. So? I dont think anybody would sleep less because of it.

Never mind. If you refuse to understand what I mean, it is pointless to explain you over and over again.

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.

But they're now changing that. More and more european laws are being introduced. Of course this was not done "right away" ... also because of legal reasons. However, that discussion doesn't belong here.

Sure, nor I believe there will ever be a cultural takeover by any European country. Napoleon failed, Hitler failed, why do you think the European Community will succeed? Don't answer, this is a rhetoric question.

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.

PEAR has no legal issues at all regarding to this. If a user wants to contribute, he needs to adopt. This is the same for the PHP C Source, the Linux kernel source and numerous other projects. It's a sane thing to have the same style throughout your project. period.

I see your point but those are completely different projects. In such projects, all the code modules interact with each other or at least with some base code. PEAR contributed packages by people that does not need any part of PEAR base code to work. Even inheriting from the base class that is not need for the package to work. Anyway, my point is that bureaucracy will only prevent more qualified developers to make the effort to adjust to the PEAR elite intolerant rules because it will make them go through an unrealistic adaptation work is that prune to the introduction of bugs in code that was clean. That was the point of origin of this thread because in fact MDB does not have more than the only 2 drivers converted because Lukas and others gave priority to convert the code to PEAR style, which I warned a long time ago that would take a long time and subject of introducing new bugs just like what happened.

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.

Like what?

What scares me in the PHP developers that are so concerned with using PHP in serious development in enterprises have no clue how medium and large scale applications are developed! Just one example, if you check the application development tools provided by big database vendors, like Oracle, Sybase, Informix, etc... you will see that provide things that are called application generation tools. Basically they depart from UML diagrams and such and generate code for your application that interfaces with the underlying database. Tools like this speed up application development by several orders of magnitude, making it viable to develop medium to large sized applications in a realistic amount of time. The problem is that such tools do not generate PHP. Most frequently they generate VB, Java and Delphi code. This means that PHP is out of the enterprise application development loop until big database vendors embrace it like they did to new languages such as Java. Sure, PHP can interface with such big vendor databases, but the problem is that it is unrealistic to try to develop everything by hand. Keep in mind that this is just one of the problems to enter seriously in the enterprise market. Sure PHP can be used in enterprise for small projects or Web pages to interface with the real systems that manage the companies businesses, but that is pretty much all.

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.

Don't think for a second I envy you.

That was not the impression that you passed me in the past, but never mind, those are past waters and I do not want to go back there again.

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.

The PEAR CS also tell about structure, not only style.

Basically, needless bureaucracy imposed to anybody that ever considered contributing. Never mind, if you do not want to see the loss of opportunity that causes to the whole PHP community, there is no point on insisting. -- Regards, Manuel Lemos