Andi Gutmans [mailto:[EMAIL PROTECTED]] wrote:
> >Seriously though - if you put comments in big enough letters in
> the header
> >and source files, and any docs that use them, stating that they are
> >much slower than the usual way of doing then we should have it covered?
> People don't read the .h files usually and copy from other extensions.

We could name the function zend_VERY_SLOW_DO_NOT_USE_parse_parameters_hash()
I understand your point though.

> >While I understand your concerns about the performance of PHP as a whole,
> >surely the performance of an extension is the concern of the extension
> >author, and perhaps they should be the one to decide if they use a fast
> >or a slow method of writing their code.  If someone misuses the API for
> >code in the PHP CVS repository then I'm sure that the people here won't
> >waste any time in jumping on the naughty author and revert the commit ;-)
> It is not only the concern of the extension author. There are many people
> on php-dev which monitor extensions for conventions & performance. In the
> end, many people are using these extensions and the PHP dev team has a
> responsibility for quality and performance. Leaving this up solely to the
> extension author is wrong.

That is more or less what I said, or what I meant to say, when I mentioned
people jumping in and reverting.

> Anyway, performance aside, there is also the point of conventions. Up to
> now, PHP has been pretty much a functional language with an
> argument list.

A convention that I like!
I don't really like the idea of so many args, but the alternative is to
expose the openssl API and do everything manually; there will be less
args per function but then there would be about 20 PHP_FUNCTION calls and
a bunch of resource zvals.
Not too nice :-)

> IMO, it should be in very specific cases where it is clearly
> beneficial to use arrays than passing 10 arguments. The guidelines should
> also take performance into account and should only allow its usage in
> functions where performance is not much of an issue.
> If we make it very clear it will be easy for PHP dev to shout
> "Hey, you're
> not allowed to use this in function foo() because of a, b, c".

I agree.


PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to