Implicit isset/isempty check on short-ternary operator View as Markdown

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

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.

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_schmidt@yahoo.com.au
mailto:mail_ben_schmidt@yahoo.com.au> 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.

On Sat, 16 Apr 2011 03:42:11 +0200, Adam Richardson simpleshot@gmail.com
wrote:

On Fri, Apr 15, 2011 at 8:46 PM, Ben Schmidt
mail_ben_schmidt@yahoo.com.auwrote:

There was also my suggestion of a "checked ternary" operator [see my

previous email in this thread.] Backwards compatible, practical, and
simple.

It doesn't address the main issues of code duplication and nullness
checking, IMHO, so isn't a contender. Even though it's simple and
compatible, it is only practical in a handful of cases.

I believe describing nullness checking as a "main" issue is a rather
strong
assessment.

I agree. To me, nullness checking is not interesting at all.

$var = $arr['key'] ?? : 'empty';

is a significant improvement over the current means and does in fact
remove
redundant code.

If I understood it correctly, this is the essense of what I want. Compared
to the original description of checked ternary I strongly object to this
working on non-arrays.

But given that constraint, my vote goes to the checked ternary operator as
well.

--
Ole Markus With

I believe describing nullness checking as a "main" issue is a rather
strong assessment.

I don't think so, obviously. :-)

$var = (isset($arr['key'])) ? $arr['key'] : 'empty';

Nullness checking is half of what that code does, isn't it? Otherwise it
would be (isset($arr['key']) && $arr['key']), right?

Additionally, it might not be as succinct as you prefer, but surely

$var = $arr['key'] ?? : 'empty';

is a significant improvement over the current means and does in fact remove
redundant code.

But it's not equivalent to your code snippet above, is it?

My vote's still with the line of discussion Hannes and I were on, of
separate 'careful array index lookup' and 'default-when-null'
operator(s). Partly because I think that approach can help everyone,
whereas the checked ternary operator really doesn't help me much at all.
Not sure if that's selfish or not. :-)

I'll try to stay a bit quieter for a bit, if I can manage it.... I've
said a lot today.

Returning due respect,

Ben.

It's good for some situations, but there are plenty more where it doesn't cut it,
e.g. $_GET[?'foo'] $:= get_default_from_db('foo') $: "hard-coded".

Ben.

what about something like this?

$_GET += array( 'key' => 42, 'other' => 'blablah' );

echo $_GET [ 'key' ];

and it's already available on you current instalation :)

Martin Scotta

On Fri, Apr 22, 2011 at 11:27 PM, Ben Schmidt<mail_ben_schmidt@yahoo.com.au

wrote:

I must say that the prospect of yet more new syntax is scary. It
really looks like Perl, and I wouldn't have the slightest clue what it
meant if I'd missed the release notes.

I agree it looks a little bit strange. I think that's partly a benefit:
it doesn't look like something so that you assume you know what it means
but get it wrong; it drives you to the manual to find out what it means.

I've pined for something like coalesce($_GET['foo'], $defaults['foo'],

42. for years, and I think that style is far more in keeping with the
    PHP ethos, and far more readily understandable than this suggested new
    syntax.

As I see it, there a are a number of drawbacks to this approach.

1. It doesn't help with a bunch of common paradigms. For instance,
   $a['k'] = isset($a['k']) ? $a['k'] : "default"

2. I think it's too 'blunt'. For instance, if you write
   coalesce($_GET['foo'], $defaults['foo']) you probably actually do want
   to see a notice if $defaults['foo'] is not defined. But if you include
   42 as a last resort default, you of course do not. Treating the last
   argument of a variable number of arguments differently is difficult and
   unintuitive, and even that would not always be desired anyway.
   Furthermore with something like $o->foo are you interested in whether $o
   is defined or not, or only in whether $o->foo is null? Particularly if
   you have many arguments, if you don't have tests that give full coverage
   of all the possibilities for each argument, notices very helpful for
   debugging could be easily undesirably silenced.

3. It can't be equivalent to isset() on every argument. isset() is very
   restricted in what it can operate on. For instance, isset(42) is not
   legal; nor is isset(some_function()); and so on. This kind of thing
   would be important to allow in coalescse(), but it would make things
   difficult to parse: to have any chance of making it work, you'd need to
   parse each item as if in isset(), and if it fails, backtrack and parse
   it as an expression, and then the coalesce() operation(s) (it could not
   be a function) would have to be able to deal with both scenarios for
   every argument. Nasty.

4. It's misleading regarding side effects because it looks like a
   function. If coalesce() were a function and you wrote
   coalesce($_GET['foo'],get_default('foo')), you would expect
   get_default() to be called before coalesce() and regardless of the state
   of $_GET['foo']. If it actually behaved like that, it would render
   coalesce() somewhat less useful, but it would be misleading if it didn't
   work like that. isset() gets away with this because it is restricted and
   only has one argument, but coalesce() wouldn't.

To avoid/solve these problems:

1. Support missing paradigms: I suppose adding coalesce_set() and other
   constructs could conceptually provide for that.

2. Less blunt: You really need some kind of notice-free array index
   and/or variable lookup that can pinpoint the notice to be omitted. A
   function-like syntax doesn't really work: isset(), though better than
   coalesce(), is still too blunt for many use cases. It's also very
   verbose. Nobody wants to write
   coalesce(ifset($_GET['foo']),ifset($defaults['foo']),42)
   IMHO, it is better to have

coalesce($_GET[?'foo'],$defaults[?'foo'],42)
even though it's not 'familiar'.

3. Avoid isset()-like restrictions: You can use a !==null test that can
   be applied to any expression; if problem 1 is solved satisfactorily, an
   expression will simply be evaluated without generating a notice, and
   then compared to null.

4. Sensible side-effect behaviour: To get that, you really need an
   operator (or other language construct), and a function-like syntax is
   misleading. Although unfamiliar,

$_GET[?'foo'] $: $defaults[?'foo'] $: 42
is less misleading. It also extends nicely to the assignment paradigm as
$_GET[?'foo'] $:= $defaults[?'foo'] $: 42;

Ben.