Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <CAL=_i_ndnBUEHUcNxPJxxkhZ70jM4xE-xkjuftWpHHNSKMchOA@mail.gmail.com>
 <BY2PR0201MB1784884D794E3FF56E08D124BF500@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAFMT4Noi+=r=oEkSHkkdYy7UJ0VCw-CH-iP8LfJOrovCMm7-bg@mail.gmail.com>
 <2f0b0366-de16-25ef-f5ca-a03fb7d6f38b@zend.com>
Message-ID: <575AE7EE.7050208@garfieldtech.com>
Date: Fri, 10 Jun 2016 11:16:46 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <2f0b0366-de16-25ef-f5ca-a03fb7d6f38b@zend.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: larry@garfieldtech.com (Larry Garfield)

On 06/10/2016 10:01 AM, Dmitry Stogov wrote:
>
>> To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
>> slowdown? In my opinion that is definitely a tolerable performance hit
>> for such a feature.
> I don't see any big value in this feature.
> Most framework access their properties through getters and setters 
> anyway.
> They can be and should be used to provide type-safe API.
> Another level of protection that makes slowdown instead of expected 
> speedup, doesn't make any sense for me.
>
> Thanks. Dmitry.

Needing an explicit getter and setter (and the overhead of the function 
call) just for type checking is a bug this feature would obviate.  If 
the only value of the getter/setter is type safety, then you're better 
off not using them.  (There are other reasons to have getters and 
setters, and I'd still love to see the property accessor RFC reborn, but 
that's a separate issue.)

Additionally, typed properties provides a terser, more self-documenting 
way of communicating the property type and thus expected behavior.  I've 
written several doctrine classes, for instance, that are 5 lines of 
properties and 30 lines of getters/setters/docs boilerplate.  If that 
boilerplate can be reduced or eliminated, that's a win.

It also provides better introspection capabilities for ORMs and similar 
serialization tools.  Yes, in some cases richer data than this RFC 
provides is helpful but not always.  In many cases this would be 
sufficient to build automated safety into automated tools. (ORMs, 
serializers, validators that now don't need to be written at all, etc.)

That seems like a worthwhile trade-off for a <1% performance difference 
in a real-world application.

--Larry Garfield