Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93696
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
To: internals@lists.php.net
References: <CAF1yvAQpOYF2JOZ2PYfofh4zQO5hgvBgnZBX_sFptgSoXCq4-A@mail.gmail.com>
 <574EAD78.5000402@lsces.co.uk>
 <CAF1yvAQxcURJ98HEZFLnN2MnJrQGTDZzAbg=Df-vJEqH+QnwOg@mail.gmail.com>
Message-ID: <574F487E.6030009@lsces.co.uk>
Date: Wed, 1 Jun 2016 21:41:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAF1yvAQxcURJ98HEZFLnN2MnJrQGTDZzAbg=Df-vJEqH+QnwOg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Set object properties inline
From: lester@lsces.co.uk (Lester Caine)

On 01/06/16 21:09, Jesse Schalken wrote:
> On Wed, Jun 1, 2016 at 7:40 PM, Lester Caine <lester@lsces.co.uk> wrote:
> 
>> Morphed into simply passing an array to the constructor ...
>>
>>         $static1         = new Data\StaticVariable( array(
>>           'name'         => 'variable name',
>>           'value'        => $unknown1,
>>           'functionName' => 'blahFunction' ) );
>>
>>         // className defaults to null
>>
>> Of cause the short cut at that time was to drop the names and simply
>> count the variables, but what this replaces is all the complications of
>> named parameters and allowed passing objects in such as '$unknown1'
> 
> This works fine to remove the temporary variable but compromises two things
> that I think are very important:

Which was the start of the discussion when 'arrays' were being pushed as
a 'solution' back in the PHP5.1/2 timescale.

>    1. IDE tooling and static analysis. An IDE can't autocomplete property
>    names as array keys, because it doesn't know the array keys are properties,
>    nor can it ensure that the properties actually exist, are visible, and are
>    being assigned the correct type. If I do a "Find Usages" on a property, it
>    may appear to be only read and never set, implying I can remove the
>    property and replace all the reads with the default value. Any static
>    analysis tool would have the same trouble.

Hard coding the list of names just so you can add 'static analysis' is
only one style of working. My set of array keys come from the database
schema, which is another way of defining and typing your parameter set.

>    2. Performance. The code spends time building a temporary hash table
>    just to loop over it, look up each key in the object's property table,
>    check visibility, check type, assign it, and discard the hash table. That's
>    a lot of overhead just to assign some properties. With a dedicated inline
>    property assignment syntax, a normal bunch of "assign property" bytecode
>    instructions can be output and the PHP runtime will cache the property
>    offsets and assign them directly, and can elide the property type check if
>    the optimiser knows it will pass. HHVM can even burn the property offset
>    right into the compiled machine code. That's *way *faster. (At least
>    that's how I was told it works when I asked here a couple of weeks ago.)

If your starting point is an array of database fields which are enhanced
with the relevant type and constraint attributes, then 'performance'
starts from that base. That was the base we were working on 15 years
ago, and trying to replace that with hard coded 'PHP only' code does not
remove that. The drive to make everything as 'static' as possible misses
the whole point that PHP is a DYNAMIC scripting system.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk