Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50EBEC0E.50908@toolpark.com>
References: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com>
 <CAF+90c9=HgRLHv4o=5dGkQzZPC5Q0tbPC8GD9AZ13Jwkr0pOcw@mail.gmail.com>
 <4ED7146272E04A47B986ED49E771E347BB3D6ABCB3@Ikarus.ameusgmbh.intern>
 <50EBD4C4.8090703@toolpark.com> <CAMyk_AbPyNQ8D_JW0FsHE6WiYs5dj=LwQgqZ691eFVFne+Hmow@mail.gmail.com>
 <50EBEC0E.50908@toolpark.com>
Date: Tue, 8 Jan 2013 11:16:33 +0100
Message-ID: <CAMyk_AZ5kaJ=e_WdBA40NvbAeT6KtRvY5dJWtkUiEqcPTY907w@mail.gmail.com>
To: Lars Schultz <lars.schultz@toolpark.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=90e6ba3fcd55bc95c504d2c43efd
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: linepogl@gmail.com (Lazare Inepologlou)

--90e6ba3fcd55bc95c504d2c43efd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013/1/8 Lars Schultz <lars.schultz@toolpark.com>

> Am 08.01.2013 10:03, schrieb Lazare Inepologlou:
>
>> The fact is that the existing syntax for nullable type hinting has its o=
wn
>> problems. For example, this is not possible:
>> function foo( Bar $bar =3D null , $mandatory ) { ... }
>>
>
> Sure it's possible;) I did not get a syntax error for that...I even use
> that case many times in my code exactly for that purpose, to allow $bar t=
o
> be null but require $mandatory to be defined explicitly.
>

Seems you are right. Sorry.


>
>  I would love to have the question mark syntax for both properties and
>> argument type hinting.
>>
>
> Introducing a BC-Break and/or yet another syntax? Is that worth it?
>
>  This does not apply in all cases. Here is an example of a property that =
is
>> guaranteed not to be null:
>>
>> class Foo {
>>    private $_date;
>>    public DateTime $date {
>>      get {
>>        return is_null($date) ? new DateTime() : $this->date;
>>      }
>>      set {
>>        $this->date =3D $value;
>>      }
>>    }
>> }
>>
>
> The property is still null;) Only the return value of the getter will not
> be null. But that's not the issue, is it? I am not arguing the case of NO=
T
> allowing null, Stas wanted to always allow null because of this reason an=
d
> not have a special syntax to declare this.
>
>
>
No, the field $_date can be null. The property $date is not null, cannot be
set to null and cannot return null. Furthermore, it cannot be unset (should
fail with an error) and isset always returns true.


Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel

--90e6ba3fcd55bc95c504d2c43efd--