Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65130
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.48 as permitted sender)
Message-ID: <51005B7F.6060209@googlemail.com>
Date: Wed, 23 Jan 2013 22:51:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: internals@lists.php.net
References: <510038C9.5000900@mrclay.org> <B103E205-5F44-4524-9BCD-7BF241F7E552@zerocue.com> <CAFMT4Nq+27=7BuqrJggjjf8mT_NBAXr7v-qzkWazFgdQLYTRew@mail.gmail.com>
In-Reply-To: <CAFMT4Nq+27=7BuqrJggjjf8mT_NBAXr7v-qzkWazFgdQLYTRew@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] C# properties vs. accessors RFC
From: cryptocompress@googlemail.com (Crypto Compress)

Hello Levi,

> Agreed, but if they are automatically generated then I see no harm in 
> allow custom `isset` and `unset` behavior as long as it doesn't get in 
> the way or complicate things.

If override of isset/unset is possible, we will end up debugging:
     true === isset($this->someUninitializedValue)
or
     unset($this->memoryConsuming); // with no effect

What is the benefit of this?


> I also don't like the `?` for `nullable`.  Just stick with PHP
> convention and do:
>
>      class Foo {
>          public Bar $bar = NULL;
>      }

There is no such PHP convention. The PHP convention is *not restrict 
type* (+"loosely typed" addons).
So NULL is automatically allowed.

cryptocompress