Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50EBD4C4.8090703@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>
Date: Tue, 8 Jan 2013 10:03:56 +0100
Message-ID: <CAMyk_AbPyNQ8D_JW0FsHE6WiYs5dj=LwQgqZ691eFVFne+Hmow@mail.gmail.com>
To: Lars Schultz <lars.schultz@toolpark.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8f3ba01b09561004d2c33bbd
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: linepogl@gmail.com (Lazare Inepologlou)

--e89a8f3ba01b09561004d2c33bbd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> It takes up the syntax php has been using for method-definitions.

The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:

function foo( Bar $bar =3D null , $mandatory ) { ... }

I would love to have the question mark syntax for both properties and
argument type hinting.

> Although, as Stas has pointed out, *not* allowing NULL for a property
will not prevent it from being NULL...depending on wether it has been
initalized.

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;
    }
  }
}



Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2013/1/8 Lars Schultz <lars.schultz@toolpark.com>

> Am 08.01.2013 08:56, schrieb Christian Stoller:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date =3D NULL;` // this looks like the property is
>> initialized with null, but it does not show that the property is 'nullab=
le'
>>
>
> To me this makes perfect sense. It takes up the syntax php has been using
> for method-definitions. A syntax we would be using to create a classic
> setter method if there wasn't a fancy new one.
>
> public function setDate(DateTime $date =3D NULL) {
>         $this->date =3D $date;
> }
>
> Anything other than this would result in an inconsistency. Having accepte=
d
> that syntax previously and now introducing yet another one, would be
> confusing and unnecessary.
>
> Although, as Stas has pointed out, *not* allowing NULL for a property wil=
l
> not prevent it from being NULL...depending on wether it has been initaliz=
ed.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--e89a8f3ba01b09561004d2c33bbd--