Marcus,
If you read what I said in my emails on this topic, it's clear that I know
that this is the case. As I said, this approach has the side effect of
creating an empty placeholder if the variable to be checked doesn't
exist. I also said that I think it would usually make more sense to simply
assign the variable with the wanted value, instead of just returning that
value, so that you don't have to clutter your code with ifsetor()'s or
whatever each coder ends up calling this (sometimes it may not be
desirable, obviously, but I assume it would be more often than not).
At the end of the day, this is really a nuance. Fact is that it's possible
to implement ifsetor() functionality today in userland. We cannot go
around implementing a new construct for every possible thing that someone
might need. This should be implemented in userland, even if it has a small
side effect. It gives you the full power of doing whatever you want,
instead of being limited to what a low level construct does.
Zeev
At 20:04 16/06/2005, Marcus Boerger wrote:
Hello Zeev,
though the idea is nice and & does what we want here to a certain level it
still doesn't allow to implement ifsetor() or coalesce() or any other flavor
described here as proved by the following snippet:
[EMAIL PROTECTED] ~ $ php -r 'function ifsetor(&$a, $def=false) { return
isset($a) ? $a : $def; } $a= array(); $x = ifsetor($a[12][34], 42);
var_dump($x); var_dump($a);'
int(42)
array(1) {
[12]=>
array(1) {
[34]=>
NULL
}
}
I expect $a to be untouched of course. May this is another reason to
implement my const pass signature info. But then it might not be
implementable for this specific problem.
best regards
marcus
Tuesday, June 14, 2005, 4:26:44 PM, you wrote:
> At 17:10 14/06/2005, Sven Fuchs wrote:
>> > This implementation of issetor() actually works fine, except it does
>> > pollute the symbol tables with empty variables ($a and $b in this
>> > examples are created, as nulls).
>>
>>What are the consequences of polluting the symbol tables this way?
> Well, it will increase memory usage, but unless you're dealing with a huge
> amount of variables, that should be pretty negligible. It might also not
> work properly in certain cases, because PHP isn't truly capable of
> differentiating between variables those empty variables and real variables
> that contain nulls. For example,
> function ifsetor(&$x) { }
> ifsetor($foo);
> print $foo;
> will not generate a notice on a non existing variable, but will emit it if
> the call to ifsetor() is removed.
>>Should this issetor() be considered a "bad practice", probably for
>>medium to large scale applications?
> I think that a more practical implementation may be something like:
> function ifsetor(&$x, $default=null)
> {
> if (!isset($x)) {
> $x = $default;
> }
> return $x;
> }
> i.e., assign the variable with the default value if it doesn't yet
> exist. I think it usually desirable (not always, naturally) and since we
> want the variable to exist in this case, there's no pollution issue.
> I fully agree with everyone else that wondered why we're discussing
> this. People can implement this on their own, the way they want it, with
> an assignment or without it, using empty() or isset(), etc.
> Zeev
--
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
