I like this - especially .7 and .8.
The $: is intuitive because it looks like a variable that doesn't contain
anything and the : specifies what comes then.
However I'd rather use the "?" character than "@" for the simple reason that
I see this as a more careful way to access an array and not as an "error
silencing operation". E.g. it's not implemented by setting error reporting
to 0 but rather... to illustrate it, let's pretend that the PHP array where
implemented by the ArrayAccess class. The "offsetGet" signature would be
changed too take an extra argument:
offsetGet( mixed $offset, boolean $unset_defined )
Normal array access would have $unset_defined set to false, but an access
like $a?[$k] would set it to true (the ?[ modifier) would make
$unset_defined become true so:
if (!$unset_defined) {
\trigger_error("Undefined index: $offset", \E_NOTICE);
}
return null;
Of course, in userland, one could implement ArrayAccess and exploit the
$unset_defined parameter in any other way. Let's for example say that you
implement it to make an ArrayAccess class that maps data to the file system,
using the file name as a $offset. If $unset_defined is set to false you
would just go ahead and try to open the file in question, possibly raising a
file operation error - however if $unset_defined is true you might make a
careful check before opening the file to see if it really exist. If error
silencing would be used instead - other errors like file permission errors
could incorrectly be silenced - but $unset_defined specifically checks if
the file exist or not before access. So it could affect the read operation
itself - and I hope that explains why It's more than just "error silencing".
~Hannes
On 15 April 2011 03:01, Ben Schmidt <mail_ben_schm...@yahoo.com.au> wrote:
> 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.
>>
>>
>>
>>
>>
