Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51889
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=OTY3PFKFOawFWArXbSW+XGOMZeb1FsE0xXNi4mmsoORr+IxKg7JbdgyBiB4+85P53Y
         C4efzdW1Syr9UVe7qLvsDTB5uiRBP9J6LY9AcFn5NsA9xm4u3OVVTuujHCIxxY8/WPQd
         3Y1mcO5P+fMi8/thZtnvOFIl2EIGWJVnKzGl0=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <4DA65BEC.8000809@gmail.com>
References: <AANLkTiknomAsTrsZ140rWs6CwxJP3UYGUokQbERhDiRp@mail.gmail.com>
	<4D950434.3060704@yahoo.com.au>
	<BANLkTinzb5xiD8j7ZXB+cT4EBZY3DF6BYQ@mail.gmail.com>
	<4D9E0543.1080600@lerdorf.com>
	<69.82.36433.EC33E9D4@pb1.pair.com>
	<4D9E34C4.5000406@lerdorf.com>
	<4D9E429B.20503@sugarcrm.com>
	<4D9E96B6.6060401@lerdorf.com>
	<BANLkTi=LvYLaOoGgrzrWfYbQ+t9Wzv_XeQ@mail.gmail.com>
	<BANLkTim6ZBWw66rzx_gSvWc9E45EZx2_gw@mail.gmail.com>
	<BANLkTinxG6FtOqa8KzmvgTT1EFfM-6prow@mail.gmail.com>
	<BANLkTinsnqGSVTz=XPhCfX95mfeJ_pkhCg@mail.gmail.com>
	<BANLkTi=nwij4sfkKnNdM_NP9w2CArK6NHQ@mail.gmail.com>
	<BANLkTikghRix9VbpHDx+rnCRtnjdjeshmg@mail.gmail.com>
	<718216446.20110408143441@cypressintegrated.com>
	<4DA0E71C.9030008@gmail.com>
	<BANLkTi=jJTO3qgjN8=3DCKAV88pnvycVsA@mail.gmail.com>
	<op.vtp8l9jnr8a5bd@localhost>
	<4DA63ED8.4080402@yahoo.com.au>
	<4DA65BEC.8000809@gmail.com>
Date: Thu, 14 Apr 2011 12:40:24 +0200
Message-ID: <BANLkTi=NY-9wOo=m2JdJZYL=L_zVrz9kFg@mail.gmail.com>
To: David Muir <davidkmuir@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0015174c1c5c88b1ea04a0de8d5a
Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
From: info@tyrael.hu (Ferenc Kovacs)

--0015174c1c5c88b1ea04a0de8d5a
Content-Type: text/plain; charset=UTF-8

inline posted


> I cry whenever I see code with @ in it...
>
>
I always cry when somebody thinks that the @ cannot be used correctly.
btw we have the scream extension and xdebug.scream also, and you could use
an error handler to "scream" the errors suppressed by @, so I don't know why
are you crying.


>
> What we're wanting are existential assignment and ternary operators.
> Simply put, a painless way to set or use a default value based on the
> existence of a variable without needing a bunch of extra code to avoid
> notices/errors. Sorry Ben, but I think extending the @ operator to
> prevent errors from being generated in the first place is a terrible
> idea. I would prefer to see @ removed from PHP if possible.
>
>
> there are cases where you can't write clean code without @.
for example there is an instruction, which can generate an error and you can
predict that it is "safe" to execute or not.
for example:
- http://php.net/manual/en/simplexmlelement.construct.php<http://hu2.php.net/manual/en/simplexmlelement.construct.php>
- http://php.net/manual/en/function.simplexml-load-file.php
which can be worked around with
http://php.net/manual/en/function.libxml-use-internal-errors.php<http://hu2.php.net/manual/en/function.libxml-use-internal-errors.php>

or another example would be serialize/unserialize:
http://www.php.net/manual/en/function.unserialize.php

it can be a perfectly valid to suppress the notice and check for the return
value of the serialize/unserialize call to handle errors locally.

another example: you have a script, which checks for a cache file, if
present then you simply read it, if not, then you generate the result and
write it to the cache file, which gets invalidated(deleted) if it's older
than x.
but you can't atomically check the existence of the file then read it. and
it can happen (race condition) that you the file was present when you
checked with file_exists, but it is deleted when you try to open it in the
next line.

I think that it could be a good idea to provide an operator to not just
change the error reporting level, but to simply prevent the error
generation.
of course its a tricky question: should we discard the error if an error
handler is registered?

Tyrael

--0015174c1c5c88b1ea04a0de8d5a--