Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64696
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50EC5F8F.8010703@mrclay.org>
References: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com>
	<CAF+90c9=HgRLHv4o=5dGkQzZPC5Q0tbPC8GD9AZ13Jwkr0pOcw@mail.gmail.com>
	<4ED7146272E04A47B986ED49E771E347BB3D6ABCB3@Ikarus.ameusgmbh.intern>
	<50EC5F8F.8010703@mrclay.org>
Date: Tue, 8 Jan 2013 19:13:57 +0100
Message-ID: <CAF+90c-JPdM1mSEEsq6n_HRcdBDjZbVWE4_co6t8gwGC9WK2dA@mail.gmail.com>
To: Steve Clay <steve@mrclay.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d042ef4a5cdf8b304d2cae839
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d042ef4a5cdf8b304d2cae839
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay <steve@mrclay.org> wrote:

> On 1/8/13 2:56 AM, Christian Stoller wrote:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date = NULL;` // this looks like the property is
>> initialized with null, but it does not show that the property is 'nullable'
>>
>
> Much agreed. After instantiation, these shouldn't behave differently:
>
> public     $foo = null;
> public Foo $foo = null;
>
> Sure, method signatures have special behavior based on a default value,
> but IMO:
> 1. those semantics aren't entirely intuitive to begin with
> 2. property initializers aren't method sigs
> 3. the semantics would apply only to some properties
>
>       public DateTime? $date;
>>
>> In C# the question mark after a type is a short hand for a generic
>> Nullable type.
>>
>
> I like that it's an established practice of doing exactly what we're
> trying to do.
>
> Could we not just make it obvious?:
>
> public Foo|null $foo;
>

I'm not going to argue whether or not determining nullability via = null is
a good or bad idea, but it's the way things currently work in PHP. Adding
other mechanisms for nullability (or multiple typehints, like it is your
suggestion) is something that may be considered, but it is outside the
scope of this RFC. Those things apply to typehints in general, not just to
property typehints. If you want pursue this further, then I would ask you
to create a separate RFC (or just a separate internals discussion maybe).

Thanks,
Nikita

--f46d042ef4a5cdf8b304d2cae839--