Re: [RFC] Property Accessors v1.2 : isset / unset "failable"
| From: | Clint Priest | Date: | Mon, 29 Oct 2012 02:26:22 +0000 |
| Subject: | Re: [RFC] Property Accessors v1.2 : isset / unset "failable" | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63699@lists.php.net to get a copy of this message | ||
That's pretty fair, that last statement... As far as an application is concerned $o->b doesn't exist because it can't be read.
Seems as though some developers are going to want to know when they've tried to violate it though... I dunno. Personally I would consider it error or warning worthy because if I made that mistake I would want to know about it, rather than never been notified of it.
Is there another class of error that would make more sense? Don't most people turn off E_NOTICE errors? Perhaps emit an E_STRICT?
On 10/28/2012 8:57 PM, David Muir wrote:
On 29/10/12 03:02, Clint Priest wrote:-- -ClintSo... to be explicit here, you think in this situation: class a { public $b {I agree with Pierre, isset() should never throw a warning/notice. The primary use of isset (that I've seen in various code-bases) is to avoid warnings/notices. Only rarely do I see it used in an expression to control application logic. The above example should not give a warning, and should return false. As far as an application is concerned, $o->b doesn't exist because it can't be read. Davidset($x) { $this->b = $x; }} } $o = new a(); if(!isset($o->b)) { /* delete files */ } echo (int)isset($o->b); /* This should return false and not emit any sort of warning/notice? */ I mean specifically, there is no getter defined, therefore the result if isset is indeterminate and while I can see it not causing execution to stop I don't see it being a good idea to not warn the developer that what they've attempted is not correct. Without a getter, isset() is not a legal call (since the value cannot be retrieved).