I agree empty() is basically useless. We already have the existing
ternary operator (and its shortcut) to do a boolean test, which is
basically the same as empty().

The way I see it, if rather than making an isset() operator that
suppresses errors and offers a default, we added both a !==null operator
for the default, and a separate error-suppression mechanism, people
could use the suppression mechanism with the existing boolean ternary
operator if they want to (I would find that useful, as I often write
things such as isset($a[$k])&&$a[$k]?"yes":"no" for that kind of thing),
and use the !==null operator without error suppression (I would find
that useful, too, to avoid typos).

In summary, with two separate, simpler mechanisms, we could tackle these
paradigms (I have used @[...] for undefined index error-suppression and
$: for !==null default):

1. $v!==null ? $v : "default"
   $v $: "default"
   with notice

2. $a[$k]!==null ? $a[$k] : "default"
   $a[$k] $: "default"
   with notice

3. isset($a[$k]) ? $a[$k] : "default"
   $a@[$k] $: "default"
   without notice

4. isset($a[$k]) ? $a[$k] : null
   $a@[$k]
   without notice

5. isset($a[$k])&&!!$a[$k]
   !!$a@[$k]
   without notice

6. isset($a[$k])&&$a[$k] ? "yes" : "no"
   $a@[$k] ? "yes" : "no"
   without notice

With !==null assignment (I've used $:=) we could also have:

7. if (!isset($a[$k])) $a[$k] = "default";
   $a[$k] $:= "default";
   without notice (the LHS of an assignment never generates one)

To avoid encouraging poor coding, we would deliberately not have:

8. isset($v) ? $v : "default"
   $@v $: "default"
   without notice

But it is a cinch to add it if enough people want it, and doing so
wouldn't affect anyone who didn't want to use it--no backward
compatibility problems on the horizon. I think that's the clincher. If
we just add an isset() operator (that suppresses errors, and gives a
default), we only get paradigms 3, 4, 5 and maybe 7, but worse, if we
want to add any of the others later, we need to design more complicated
new operators, or break backward compatibility, not just extend what we
have.

I personally use 1, 3, 5 and 6 quite often, and 2 and 7 occasionally, so
I see great value in being able to do them all, not just the restricted
set.

What numbers are others interested in being able to solve?

What do others think about the future-proofing issue?

Ben.



On 15/04/11 1:01 AM, Hannes Landeholm wrote:
I can agree that implementing ?? with isset() and not array_key_exists() would 
be
acceptable... but empty() is a blunt compromise and much less used... The 
general
problem is the notice being thrown when array indexes doesn't exist - which
results in code duplication when you deal with it nicely. empty() tries to be a
generic solution but there will always be people that has some other special
definition of "emptiness" like "array that contains a single null value" and 
they
need to write the code that defines that particular comparison anyway.

You can't have a solution that makes everything easier for everyone so let's 
solve
one thing at a time and start with the most generic problem specifically and not
all minor problems that happens to partially intersect that one.

~Hannes


On 14 April 2011 16:26, Ben Schmidt <mail_ben_schm...@yahoo.com.au
<mailto:mail_ben_schm...@yahoo.com.au>> wrote:

    On 15/04/11 12:05 AM, Hannes Landeholm wrote:

        Trying to summarize this discussion... I think we can all agree that the
        main problem is "code duplication for array access when parameters are
        possibly not existing".


    For me the problem is 'code duplication when a value might be null'
    (whether an array, variable or something else, and regardless of whether
    it was set to null, or not defined at all).


        I think we all can also agree that @ can be both used properly and
        misused - and it is a blunt tool and not a nice solution to the
        previously stated problem.


    Yes.


        Some suggested that the ternary if comparison should suppress the notice
        automatically. This would break existing code and also be confusing 
since
        people expect a ternary if and normal if to work the same way.


    Yes.


        Some suggested ?? as an array access operator that suppresses the 
notice and
        has 3 variants: A: nothing specified - uses null as default, B: has 
default
        specified, C: returns X if index exists or Y if index doesn't exist. 
This
        effectively solves the code duplication problem and is a shortcut for 
saying
        "the array index may or may not exist".


    This only works if the test is made an isset() kind of test. If it
    remains a boolean cast, it doesn't help much. (Or at least it doesn't
    help me much.)

    I also think it's a bit too blunt. In all but the simplest expressions
    in the condition, desired notices could be silenced. I like the idea of
    being able to specify exactly which array lookups should be silenced.

    It also doesn't help the people who want an isset() style test, but
    without the notice suppression, and I think there are a few people in
    that category.


        One person said that the relation between ? and ?? and == and === would 
make
        the operator non-intuitive. Other people disagreed and claimed the 
opposite.

        So basically the discussion now is what exact characters that should be 
used
        to represent this operator? I really hope we can get this implemented
        quickly... I worked with $_POST yesterday and I could really use that ??
        operator.


    I still don't think we've reached agreement on exactly what we need.
    Your summary seems to me to be of some of the earliest and least
    developed ideas. I think the discussion has moved in a number of
    interesting directions since then and we should draw on that later work.

    Ben.





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to