Em Fri, 20 Jul 2012 02:07:31 +0200, Stas Malyshev <smalys...@sugarcrm.com>
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
idiomatic just yet.
OK I should have qualified my statement -- it's idiomatic in userland.
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 perfectly good concept "default means no
parameter" which won't clash with any existing code?
Note that this still will require something like l! - I'm actually
working right now on finding all the places we have something like this
for my default params patch - so I agree with that part of the argument.
I'm just not sure adding that semantics to null is the best idea, since
null can be a variable value and having something like mb_substr($foo,
0, $this->length) suddenly behave differently when $this->length is null
would be somewhat unexpected effect.
I don't deny that 'default' would be clearer than 'null' (and certainly
clearer than 3 commas in a row), but I wouldn't call this strategy
innovative. A lot of userland code out there uses NULL in this fashion.
I already had the opportunity to express my reservations about your
proposal -- namely the effort required to purge ZEND_NUM_ARGS() usage vs
the benefit, but since 1) you're apparently doing the work, 2) eases
somewhat the way for named parameters, and 3) the default keyword was
added, it doesn't seem so bad now.
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.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
