Re: [PHP-DEV] zend_parse_parameters()
On Sun, Dec 30, 2001 at 04:09:54PM -0500, Sean R. Bright wrote : Is the goal to existing code over to use the zend_parse_parameters() function or just those functions that take more than one parameter/ optional parameters? The point to use the never API is the unified error messages, in most cases easier access to the passed variables and a cleaner and easier to review interface to acess the args (with a glance at the args specified you know what to expect regardless of the maybe wrong doc proto for example). It's the prefered API but it's not necessarily needed to convert old API (most people do this when they fix a bug somewhere to convert it too). - Markus -- Please always Cc to me when replying to me on the lists. -- 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]
Re: [PHP-DEV] zend_parse_parameters()
You're trying to fit a double into an int .. doesn't seem
right to me. int is 4 bytes, double 8 bytes (at least on i386
here).
- Markus
On Tue, Dec 04, 2001 at 02:47:05PM +0100, Mathieu Kooiman wrote :
For my module I've been playing with zend_parse_parameters().
I ran into something weird though:
--
zval *rsrc_pdb;
char *data;
int s_len = 0, index = 0, mode = PDB_ADD_APPEND;
if ( zend_parse_parameters ( ZEND_NUM_ARGS() TSRMLS_CC, rsdd,
rsrc_pdb, data, s_len, index, mode) == FAILURE) {
return;
}
--
This works. As in, it doesn't return FAILURE. However, after
inspecting this with gdb, s_len seems to still be 0 after calling
zend_parse_parameters()..
Am I doing something wrong or is zend_parse_parameters() ??
Mathieu
--
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]
--
Please always Cc to me when replying to me on the lists.
--
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]
Re: [PHP-DEV] zend_parse_parameters()
On Tue, 2001-12-04 at 15:02, Markus Fischer wrote:
You're trying to fit a double into an int .. doesn't seem
right to me. int is 4 bytes, double 8 bytes (at least on i386
here).
- Markus
README.PARAMETERS_PARSING_API tells me 's' gets you the string
and it's length..
Quote:
Examples
/* Gets a long, a string and its length, and a zval */
long l;
char *s;
int s_len;
zval *param;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, lsz,
l, s, s_len, param) == FAILURE) {
return;
}
So IMO, my code should work..
On Tue, Dec 04, 2001 at 02:47:05PM +0100, Mathieu Kooiman wrote :
For my module I've been playing with zend_parse_parameters().
I ran into something weird though:
--
zval *rsrc_pdb;
char *data;
int s_len = 0, index = 0, mode = PDB_ADD_APPEND;
if ( zend_parse_parameters ( ZEND_NUM_ARGS() TSRMLS_CC, rsdd,
rsrc_pdb, data, s_len, index, mode) == FAILURE) {
return;
}
--
This works. As in, it doesn't return FAILURE. However, after
inspecting this with gdb, s_len seems to still be 0 after calling
zend_parse_parameters()..
Am I doing something wrong or is zend_parse_parameters() ??
Mathieu
--
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]
--
Please always Cc to me when replying to me on the lists.
--
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]
--
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]
Re: [PHP-DEV] zend_parse_parameters()
Yo !
But you specified two doubles dd after the string and try to fit
them into ints!
- Markus
On Tue, Dec 04, 2001 at 03:00:13PM +0100, Mathieu Kooiman wrote :
On Tue, 2001-12-04 at 15:02, Markus Fischer wrote:
You're trying to fit a double into an int .. doesn't seem
right to me. int is 4 bytes, double 8 bytes (at least on i386
here).
- Markus
README.PARAMETERS_PARSING_API tells me 's' gets you the string
and it's length..
Quote:
Examples
/* Gets a long, a string and its length, and a zval */
long l;
char *s;
int s_len;
zval *param;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, lsz,
l, s, s_len, param) == FAILURE) {
return;
}
So IMO, my code should work..
On Tue, Dec 04, 2001 at 02:47:05PM +0100, Mathieu Kooiman wrote :
For my module I've been playing with zend_parse_parameters().
I ran into something weird though:
--
zval *rsrc_pdb;
char *data;
int s_len = 0, index = 0, mode = PDB_ADD_APPEND;
if ( zend_parse_parameters ( ZEND_NUM_ARGS() TSRMLS_CC, rsdd,
rsrc_pdb, data, s_len, index, mode) == FAILURE) {
return;
}
--
This works. As in, it doesn't return FAILURE. However, after
inspecting this with gdb, s_len seems to still be 0 after calling
zend_parse_parameters()..
Am I doing something wrong or is zend_parse_parameters() ??
Mathieu
--
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]
--
Please always Cc to me when replying to me on the lists.
--
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]
--
Please always Cc to me when replying to me on the lists.
--
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]
Re: [PHP-DEV] zend_parse_parameters()
You're right, sorry :-)
Thanks Markus.. (and Derick too :D )
-- Mathieu
On Tue, 2001-12-04 at 15:07, Markus Fischer wrote:
Yo !
But you specified two doubles dd after the string and try to fit
them into ints!
- Markus
On Tue, Dec 04, 2001 at 03:00:13PM +0100, Mathieu Kooiman wrote :
On Tue, 2001-12-04 at 15:02, Markus Fischer wrote:
You're trying to fit a double into an int .. doesn't seem
right to me. int is 4 bytes, double 8 bytes (at least on i386
here).
- Markus
README.PARAMETERS_PARSING_API tells me 's' gets you the string
and it's length..
Quote:
Examples
/* Gets a long, a string and its length, and a zval */
long l;
char *s;
int s_len;
zval *param;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, lsz,
l, s, s_len, param) == FAILURE) {
return;
}
So IMO, my code should work..
On Tue, Dec 04, 2001 at 02:47:05PM +0100, Mathieu Kooiman wrote :
For my module I've been playing with zend_parse_parameters().
I ran into something weird though:
--
zval *rsrc_pdb;
char *data;
int s_len = 0, index = 0, mode = PDB_ADD_APPEND;
if ( zend_parse_parameters ( ZEND_NUM_ARGS() TSRMLS_CC, rsdd,
rsrc_pdb, data, s_len, index, mode) == FAILURE) {
return;
}
--
This works. As in, it doesn't return FAILURE. However, after
inspecting this with gdb, s_len seems to still be 0 after calling
zend_parse_parameters()..
Am I doing something wrong or is zend_parse_parameters() ??
Mathieu
--
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]
--
Please always Cc to me when replying to me on the lists.
--
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]
--
Please always Cc to me when replying to me on the lists.
--
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]
--
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]
Re: [PHP-DEV] zend_parse_parameters
At 14:44 09-09-01, Jani Taskinen wrote: ..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. Go ahead, you're welcome to do that. Seriously Jani, stop bugging us with requests to do things. It's still an opensource project and we, like anybody else, work on what we feel like working. By the way, your post had absolutely nothing to do with the subject of the discussion. Zeev -- 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]
[PHP-DEV] Re: Documenting ZE (was: Re: [PHP-DEV] zend_parse_parameters)
I've wanted to suggest for a while that there be an option to annotate the API docs on Zend's site. There have been a few things ive discovered in the process of extension development that could benefit fellow travelers, but as of now there seems not to be a process (that im aware of) to accomodate additional input. im suggesting annotations because most of what i can contribute are disjointed bits of info that dont necessarily add up to a distinct topic. Zeev Suraski [EMAIL PROTECTED] wrote in message 5.1.0.14.2.20010909203210.0404ceb0@localhost">news:5.1.0.14.2.20010909203210.0404ceb0@localhost... At 20:22 09-09-01, Jani Taskinen wrote: I don't think I have really 'bugged' you about it so far. Once is once too many, but anyway, I don't take count of who bugged me with what. It's definitely not the first time I'm bugged with this... I'm not sure I did, but at least Andi said numerous times that he welcomes anybody who wants to document the engine. Personally, I think that updating the API docs we already have is better than going in the protos path, but any effort is good. Zeev -- 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]
Re: [PHP-DEV] zend_parse_parameters
At 09:33 PM 9/7/2001 +0100, Wez Furlong wrote:
On 07/09/01, Andrei Zmievski [EMAIL PROTECTED] wrote:
If this is implemented (I think Andi may have some thoughts about this),
Hopefully not bad thoughts!
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. There are very few
functions which accept arrays as parameters and most of them are functions
which act on Hashes so it makes sense.
I think when you supply an API function like this which is very easy to
use, it will start being misused quickly!
What cases do you feel this is needed and are you sure regular argument
lists aren't good enough?
Andi
zend_parse_parameters_hash(HASH_OF(my_zval), {s:firstname}|{s:lastname}
{l:age}, firstname, firstname_len, lastname, lastname_len, age);
Yes - much better. I originally thought of something like this (a bit
like the python dictionary syntax people have been talking about recently):
s%(firstname)|s%(lastname)l%(age)
But that is hard to read, so I thought of splitting it up.
--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]
Re: [PHP-DEV] zend_parse_parameters
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]
Re: [PHP-DEV] zend_parse_parameters
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]
Re: [PHP-DEV] zend_parse_parameters
On Sat, 08 Sep 2001, Andi Gutmans wrote: 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. The real solution to this, of course, would be keyword arguments. How about them for v2? -Andrei In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton -- 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]
RE: [PHP-DEV] zend_parse_parameters
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. --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]
Re: [PHP-DEV] zend_parse_parameters
At 18:14 08-09-01, Andrei Zmievski wrote: The real solution to this, of course, would be keyword arguments. It's not really a solution, as this would also be slow (except for fairly rare cases, where we might be able to do the work in compile time). How about them for v2? I think we should concentrate on the features that were already discussed for v2.0. We have a lot to work on as it is, and there'll be versions afterwards. At any rate, as this came up several times in the past, perhaps somebody should write an RFC about it, so that if we want to add it in a future version, we have a basis to work on. Zeev -- 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]
Re: [PHP-DEV] zend_parse_parameters
On 07/09/01, Andrei Zmievski [EMAIL PROTECTED] wrote:
If this is implemented (I think Andi may have some thoughts about this),
Hopefully not bad thoughts!
zend_parse_parameters_hash(HASH_OF(my_zval), {s:firstname}|{s:lastname}
{l:age}, firstname, firstname_len, lastname, lastname_len, age);
Yes - much better. I originally thought of something like this (a bit
like the python dictionary syntax people have been talking about recently):
s%(firstname)|s%(lastname)l%(age)
But that is hard to read, so I thought of splitting it up.
--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]
Re: [PHP-DEV] zend_parse_parameters
At 23:33 07-09-01, Wez Furlong wrote: On 07/09/01, Andrei Zmievski [EMAIL PROTECTED] wrote: If this is implemented (I think Andi may have some thoughts about this), Hopefully not bad thoughts! They are bad thoughts, actually... The main reason against it is that it's ultra slow, many times slower than what we have today. That, combined with the fact that what you give in the API, people will use and abuse, was the main reason against it. Zeev -- 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]
Re: [PHP-DEV] zend_parse_parameters
On Fri, 24 Aug 2001, Wez Furlong wrote: When parsing strings from parameters with zend_parse_parameters, it is required that the programmer pass in an int to receive the length of the string. Could we relax this and allow a NULL instead if we do not need the length of the string? It would make the calling code more pretty because we would not need to declare a bunch if ints that don't otherwise get used. Yeah, I know about binary safety, but when I'm passing this stuff to binary unsafe functions there doesn't seem much point :) Initially, I had another specifier that would let you receive just the string pointer, but in discussions with Andi we agreed that it would be good to always return the length as well. Binary safety was a major consideration in this. Don't you think people will start passing NULL all the time if this rule is relaxed? -Andrei It is commonly the case with technologies that you can get the best insight about how they work by watching them fail. -- Neal Stephenson -- 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]
Re: [PHP-DEV] zend_parse_parameters
On 24/08/01, Andrei Zmievski [EMAIL PROTECTED] wrote: Initially, I had another specifier that would let you receive just the string pointer, but in discussions with Andi we agreed that it would be good to always return the length as well. Binary safety was a major consideration in this. Don't you think people will start passing NULL all the time if this rule is relaxed? I understand, and yes, they would. It just seems a shame to have to declare those ints when they are not used. zend_parse_parameters does a great job of reducing the tedium and clutter of declaring a php function, so I should just be grateful and keep my mouth shut :) --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]
Re: [PHP-DEV] zend_parse_parameters
On Fri, 24 Aug 2001, Wez Furlong wrote: I understand, and yes, they would. It just seems a shame to have to declare those ints when they are not used. If you come up with a solution that covers both fronts, I promise we'll consider it. :) zend_parse_parameters does a great job of reducing the tedium and clutter of declaring a php function, so I should just be grateful and keep my mouth shut :) Good, so people are starting to use it.. -Andrei Politics is for the moment, an equation is for eternity. -- Albert Einstein -- 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]
