At 11:01 AM 9/8/2001 +0100, Wez Furlong wrote:
>On 08/09/01, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > I do have some bad thoughts about it. I'm worried that if we supply
> such an
> > easy function to parse incoming hash table's people will start writing a
> > lot of PHP functions which accept hash tables instead of regular argument
> > lists. This is much slower and I think it's better to stay with the way
> > functions are written today and not change the standard.
>
>I can see your point, but, for the few cases where it is justified it
>reduces the readability -> maintainability of the code.
>
> > What cases do you feel this is needed and are you sure regular argument
> > lists aren't good enough?
>
>If you have a function that can take a lot of parameters (more than 6, say),
>the parameter parsing code begins to clutter up the actual function of
>the code. This isn't so bad, but when you are getting past 10 parameters,
>most of which are optional, it becomes a bit of a pain to manage and more
>of a pain to use from PHP user space.
>
>I know that, ideally, a functional shouldn't take so many args but in this
>case (creating a CSR and/or certificate) there are loads of parameters that
>should be able to be specified but don't need to be. The best way of
>handling this (IMHO) is pass in a hash as this is the nearest equivalent
>to passing a structure ala C.
>
> > I think when you supply an API function like this which is very easy to
> > use, it will start being misused quickly!
>It could be a secret API; lets pretend it isn't implemented and then
>implement it anyway; I won't tell anyone :)
>
>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.
>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.
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.
It might make sense for big certificates to be passed as arrays. But
instead of going ahead and diving into the code, I think it'd be a good
idea if we came up with guidelines for the cases where it's OK to pass
arrays. 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 don't want to be a pain but I want to make sure we don't start a bad
status quo. From my experience, you make this kind of stuff available and
it gets misused very quickly.
Andi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
