Em 2012-12-19 22:07, Nikita Popov escreveu:
On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes
wrote:
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as allow integer or
NULL* or the more general allow different types for an argument**.
So I propose
On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes wrote:
> Some deficiencies in zpp have been constrai
> ning the implementation of common scenarios such as 'allow integer or
> NULL'* or the more general 'allow different types for an argument'**.
>
> So I propose the changes in this branch:
>
> http
hi Gustavo,
On Sat, Jul 21, 2012 at 2:11 PM, Gustavo Lopes wrote:
> Em Sat, 21 Jul 2012 13:13:23 +0200, Pierre Joye
> escreveu:
>
>
>> On Fri, Jul 20, 2012 at 12:20 AM, Sara Golemon wrote:
>>>
>>> Okay, well... the main pieces of feedback I'd give on it then is to not
>>> change the behavior of
Em Sat, 21 Jul 2012 13:13:23 +0200, Pierre Joye
escreveu:
On Fri, Jul 20, 2012 at 12:20 AM, Sara Golemon wrote:
Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC.
Fully agreed, if we can avoid the introduction o
hi!
On Fri, Jul 20, 2012 at 12:20 AM, Sara Golemon wrote:
> Okay, well... the main pieces of feedback I'd give on it then is to not
> change the behavior of the '!' modifier. That's bad BC.
Fully agreed, if we can avoid the introduction of yet another set of
#ifdef, then I'm all for it.
> Rat
Hi!
> support. At least as far as I can tell, people are really interested
> in having named parameters, but would rather not have parameter
> skipping as implemented.
Which people? So far I've got only one person objecting - namely Gustavo
- and he's OK with it with my changes as far as I can se
On Fri, Jul 20, 2012 at 2:07 AM, Stas Malyshev wrote:
> I was just thinking - since we have basically no code relying on this,
> why introduce rather artificial concept of "null means no parameter"
> (which I'm sure won't work in all cases and won't be expected in all
> cases) if we can have perfe
Hi!
> And just to clear, I agree with Sara that ! (both for l/d/b and the
> pointer types) should not be redefined to "parameter was passed". But it's
> my understanding that that's not what you're planning.
I didn't have yet a good generic way to handle l/d/b with 'default' - in
many cases f
Em Fri, 20 Jul 2012 02:07:31 +0200, Stas Malyshev
escreveu:
Default parameters and unpassed parameters enter the scene because it's
idiomatic to pass NULL to have the same effect as not passing that
parameter.
Actually, as it never worked with int parameters, I'd not really call it
idiomati
Hi!
> Default parameters and unpassed parameters enter the scene because it's
> idiomatic to pass NULL to have the same effect as not passing that
> parameter.
Actually, as it never worked with int parameters, I'd not really call it
idiomatic just yet.
I was just thinking - since we have bas
Em Fri, 20 Jul 2012 00:20:49 +0200, Sara Golemon
escreveu:
Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC. Rather,
introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two se
On Fri, Jul 20, 2012 at 12:20 AM, Sara Golemon wrote:
> Okay, well... the main pieces of feedback I'd give on it then is to not
> change the behavior of the '!' modifier. That's bad BC.
The behavior for pointer-params isn't changed. Only non-pointer params
will then accept the additional is_null
Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC. Rather, introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two separate patches as the new modifier is a separate feature from
the si
Hi!
> This solves two problems:
>
> a) Integer parameters cannot currently be skipped using NULL. This
> issue comes up every now and then. E.g. see
> https://github.com/php/php-src/pull/133.
Again, I think param skipping RFC addresses this better, but having some
way to see if param was supplie
On Thu, Jul 19, 2012 at 11:23 PM, Sara Golemon wrote:
> Then I'm not sure what problem you're trying to solve either. :/
This solves two problems:
a) Integer parameters cannot currently be skipped using NULL. This
issue comes up every now and then. E.g. see
https://github.com/php/php-src/pull/13
Then I'm not sure what problem you're trying to solve either. :/
On Thu, Jul 19, 2012 at 12:08 PM, Gustavo Lopes wrote:
> Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon
> escreveu:
>
>
> For this type of situation, you could equally go with something like:
>>
>> zval *val;
>> if (zend_parse_p
Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon
escreveu:
For this type of situation, you could equally go with something like:
zval *val;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "n", &val) ==
FAILURE)
{ RETURN_NULL(); }
Where the 'n' type looks for a numeric value: IS_LONG
For this type of situation, you could equally go with something like:
zval *val;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "n", &val) == FAILURE)
{ RETURN_NULL(); }
Where the 'n' type looks for a numeric value: IS_LONG/IS_DOUBLE kept as is,
IS_STRING/IS_OBJECT (with toString() behavior
Em Thu, 19 Jul 2012 01:11:38 +0200, Stas Malyshev
escreveu:
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone
Hi!
> Some deficiencies in zpp have been constrai
> ning the implementation of common scenarios such as 'allow integer or
> NULL'* or the more general 'allow different types for an argument'**.
>
> So I propose the changes in this branch:
>
> https://github.com/cataphract/php-src/compare/zpp_i
On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes wrote:
> Some deficiencies in zpp have been constrai
> ning the implementation of common scenarios such as 'allow integer or NULL'*
> or the more general 'allow different types for an argument'**.
>
> So I propose the changes in this branch:
>
> http
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.
So I propose the changes in this branch:
https://github.com/cataphract/php-src/compare/zpp_improv
Please see
22 matches
Mail list logo
