Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64607
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: <50E9BEAD.9050300@zerocue.com>
Date: Sun, 06 Jan 2013 12:13:01 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Pierre Joye <pierre.php@gmail.com>
CC: "internals@lists.php.net" <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> <508ED5A4.9010100@sugarcrm.com> <50909CDF.9090505@zerocue.com>
In-Reply-To: <50909CDF.9090505@zerocue.com>
Content-Type: multipart/alternative;
 boundary="------------000007050707030508050901"
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
From: cpriest@zerocue.com (Clint Priest)

--------------000007050707030508050901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Bringing up this old issue a bit.

Nothing was ever said of unset?  Should unset be benign?

Since unset() is intended to take an action (rather than check on state) 
shouldn't an invalid unset (one with a guarded property that doesn't 
have a setter) emit a warning?

On 10/30/2012 10:37 PM, Clint Priest wrote:
> Would you say the same of unset?  Always benign?
>
>
> On 10/29/2012 2:14 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> 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? */
>> isset should return false, since $b is not set value. It should not
>> produce any warning. Of course (int) would produce 0 then ;)
>>
>>> I mean specifically, there is no getter defined, therefore the result
>>> if isset is indeterminate and while I can see it not causing execution
>> No, the result is determinate - it's false. That's the point of isset()
>> in PHP and that's how it is used in existing code.
>>
>>> 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).
>> isset() should always be legal. This is the way to check if $o->b is 
>> legal.
>>
>>
>

-- 
-Clint

--------------000007050707030508050901--