Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63699
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
Message-ID: <508DE94E.30103@zerocue.com>
Date: Sun, 28 Oct 2012 21:26:22 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: David Muir <davidkmuir@gmail.com>
CC: Pierre Joye <pierre.php@gmail.com>, internals@lists.php.net
References: <508A68B9.1050801@zerocue.com> <508AA48D.5010903@sugarcrm.com> <508C1C4F.6060406@zerocue.com> <CAEZPtU51k7zULCoHvk=vJEPTM+qHtDpgE=jPKQDQa5EZ6NgnbA@mail.gmail.com> <508D5726.8080200@zerocue.com> <508DE27C.4040007@gmail.com>
In-Reply-To: <508DE27C.4040007@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
From: cpriest@zerocue.com (Clint Priest)

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:
>> So... to be explicit here, you think in this situation:
>>
>> class a {
>>   public $b {
>>      set($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).
>>
>
> 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.
>
> David
>
>
>

-- 
-Clint