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?
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 ;-)
--Wez.
--
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]
