Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93698
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <574F487E.6030009@lsces.co.uk>
References: <CAF1yvAQpOYF2JOZ2PYfofh4zQO5hgvBgnZBX_sFptgSoXCq4-A@mail.gmail.com>
	<574EAD78.5000402@lsces.co.uk>
	<CAF1yvAQxcURJ98HEZFLnN2MnJrQGTDZzAbg=Df-vJEqH+QnwOg@mail.gmail.com>
	<574F487E.6030009@lsces.co.uk>
Date: Wed, 1 Jun 2016 23:09:28 +0200
Message-ID: <CADqTB_jARvGHQCDtKXEs0_eB2q8P2H2E0zgZrXxzFkR3g8AwHQ@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11457d64b25ac105343de7e1
Subject: Re: [PHP-DEV] Set object properties inline
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a11457d64b25ac105343de7e1
Content-Type: text/plain; charset=UTF-8

> The drive to make everything as 'static' as possible misses
> the whole point that PHP is a DYNAMIC scripting system.

I think that line of argumentation is pretty outdated - it may have been
valid many years ago, but by now, PHP is not purely dynamic; far from it.
It's a gradually-typed language, and more so with scalar type-hints
recently added, and typed properties and nullable types coming up.

The drive to enhance the static side of the language doesn't miss a point,
nor does it take away from the dynamic side of the language - the whole
point of gradually-typed languages is the ability to choose between static
and dynamic in each situation.

This tendency to "defend" the dynamic side of the language, as though
static features were somehow an "attack" on dynamic features, befuddles me.

These two sides of the language do not compete with each other - they
complement each other.

Just interjecting a general remark here, I'm not commenting on the proposed
feature specifically.


On Wed, Jun 1, 2016 at 10:41 PM, Lester Caine <lester@lsces.co.uk> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11457d64b25ac105343de7e1--