Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64586
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender)
Message-ID: <50E8CBD4.9090000@sugarcrm.com>
Date: Sat, 05 Jan 2013 16:56:52 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com> <19D80B01-BE88-4119-8A15-B631A96060E5@mrclay.org> <CAF+90c9=HgRLHv4o=5dGkQzZPC5Q0tbPC8GD9AZ13Jwkr0pOcw@mail.gmail.com> <CAHjTTqOwrCfprcw3jCiLU21NygYCjrz+3+zpjdnU_sj-JbQonQ@mail.gmail.com> <50E8AA4D.5090207@sugarcrm.com> <CAAyV7nFW45f5vEUkZXhbgaJe=TL1Tbfp7igbUkQ=ifJc9tAsvQ@mail.gmail.com> <50E8C2BA.9080309@sugarcrm.com> <CAAyV7nHk0yqgsatAo46ThDbYRtNPVmVGCPh1jshpXVY6fXkFSA@mail.gmail.com>
In-Reply-To: <CAAyV7nHk0yqgsatAo46ThDbYRtNPVmVGCPh1jshpXVY6fXkFSA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> No, the other initializer that would be useful is `new Foo`. Assigning a

You really put it in the same answer as telling me it's the same as
parameter defaults? Here you introduce completely new concept, not
existing in PHP at all - non-constant initializers. And this is a whole
new can of worms - when it should be run, what should happen when it's
run, what is the order, etc. And we already have a perfectly good place
to do this - constructors. We don't really need this whole new level of
complications with dynamic initializers, just do it in the constructor.

> As far as "why not just make it always allow null" is that it half
> defeats the point of typed accessors in the first place. Java has huge

Of course it does not. It would be really useless addition if the whole
point of it was not allowing nulls in variables, and pointless too,
since there's no way do to it. Even with initializers, how you guarantee
that no code is run before your initializer? Like another initializer?
You can not. So you always have a possibility of having null. It is true
in any language, not just Java - pretty much any language that has
object types also has "empty" value.

> issues with null pointers. And if you set the property in the
> constructor (and it's typed), you should never have the chance for it to
> be non-null, unless you explicitly define it that way. Otherwise, you'd

And you will have to ensure constructor never accesses this property,
constructor can never be extended with a code that uses this property,
constructor never calls any outside method that may use this property,
etc., etc. The complexity of this "solution" quickly gets out of hand
and does not guarantee anything in fact. And now you also have to deal
with unset() failing with a fatal error, too.

> explicitly Not allowing null. In fact, I'd argue that the "not allow
> null" use-cases are the most frequent and most critical ones...

If the whole point of this feature is to save is_null check, I do not
think we need it in PHP, since it can not guarantee it, and it does much
more and changes much more in the language than simple is_null check.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227