Re: [PHP-DEV] zend_parse_parameters From: Jani Taskinen (sniper <email protected>)
Date: 09/09/01

"..People don't read the .h files usually and copy from other extensions.."

If ZE was properly documented, people didn't have to rely on
only the sources.

Like I suggested earlier, by adding at least protos there
would help the documentation effort..ie. START it.

--Jani

On Sat, 8 Sep 2001, Andi Gutmans wrote:

>At 11:01 AM 9/8/2001 +0100, Wez Furlong wrote:
>>On 08/09/01, "Andi Gutmans" <andi <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: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>