Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93517
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.52 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <CAL=_i_mcJoFnPgeU5FQCJN=SDYnNK7Jz8zoVMv9EMuWaGRYSMg@mail.gmail.com>
 <BY2PR0201MB17845690B6386D75AF4C3D79BF4F0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAL=_i_=EqNoHvXmY+RdQW-reC4YF8AkuWFtGGJGOOSqX4a010g@mail.gmail.com>
 <cfe8404a-54f6-24b7-0ba8-8f807c820821@zend.com>
 <CAL=_i_kze8MNSmpg4WT+EJCRPmvty=8DA6DkuHSx+WCBzJjytg@mail.gmail.com>
 <CAF+90c9cBqKfy_q5rME1u56Rq366niYUBDTY+3_2iFJSZD9fDA@mail.gmail.com>
 <80.72.63510.DAFA5475@pb1.pair.com>
 <68fd73e7-ad19-3758-7b7a-6013cc26385f@gmail.com>
 <F7.23.14311.2DCC5475@pb1.pair.com>
Message-ID: <c2113a1d-99ee-fe0c-731c-d509019a9dea@gmail.com>
Date: Wed, 25 May 2016 10:10:11 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <F7.23.14311.2DCC5475@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> It'd be a BC break if we changed untyped properties' behaviour, yeah. We

It's not that simple. Lots of code operates on sets of properties or
dynamic properties, not one specific property. That code now assumes
properties default to null. If there's another default, then all that
code will have to be changed in case somebody somewhere defines a typed
property.
The impact is that as soon as one typed property appears anywhere in the
code, pretty much all the code that deals with properties (within
affected property set) has to be changed to accommodate it. Unlike
parameters, which are local to function, properties are important across
big chunks of the code.

> wouldn't be inventing a new null, though, we'd be leaving the property
> undefined until it's initialised, which we already have support for
> (properties, and indeed all variables can be unset()).

unset() now causes the property to disappear - as if it were never
defined. But you probably expect something different? So what isset()
would return for such property? What would is_null() return? What would
gettype() return?

>>> A simple example might be a Lisp-style linked list cell:
>>>
>>>      class LinkedList
>>>      {
>>>          public int $head;
>>>          public ?LinkedList $tail;
>>>      }
>>>
>>> In a properly initialised LinkedList, the $head is some value, and the
>>> $tail is either another linked list (the remainder of the list), or null
>>> (we're at the end of the list).
>>
>> This is a very weird list, as it can't be empty.
> 
> The empty list is represented by null in this arrangement.

null and empty list are very different thing. null is nothing, empty
list is an object of type LinkedList which just happens to not contain
any values. You can call methods on empty list - e.g. add elements to it
or check if it's empty or compare or concatenate with other list, etc. -
but you can't do it on null. Making assumption that null and an empty
container is the same is not a good idea usually.

-- 
Stas Malyshev
smalyshev@gmail.com