Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93595
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: <20160525215208.034FC1A801B3@dd1730.kasserver.com>
 <e194be7d-2d72-945c-b8de-245e91f6f239@thefsb.org>
 <CAO3MkaD==1jQvS_cRbDrBQ7nkoBvoAaavmgxeMiP0mSKXL7eRQ@mail.gmail.com>
 <D36C9366.6E7CA%fsb@thefsb.org>
 <5fd54aa0-4fdf-c1e7-eae8-765aa89c8498@fleshgrinder.com>
 <cb4f05df-c5fa-68db-453a-274d42c2c15e@gmail.com>
 <08963b03-8394-6d62-4e5b-393f3fcb5647@fleshgrinder.com>
 <9e9db70d-d72d-d93e-0c81-18c2aa228618@gmail.com>
 <409002d8-b5e3-5990-7358-246adc7e3cab@fleshgrinder.com>
 <57474A08.80807@lsces.co.uk>
 <6f7403b6-bf22-a12b-dfb2-43fe82983e7d@fleshgrinder.com>
 <57474F9C.6080104@lsces.co.uk>
 <1733cfce-001b-1079-e929-88f7dde0f2dd@gmail.com>
 <57475F27.3090306@lsces.co.uk>
 <50f5d1c9-d24f-1afe-4c34-70aafd981524@fleshgrinder.com>
 <5747697A.7000906@lsces.co.uk>
 <37377d3b-827a-4cfd-580b-e33862084ab6@gmail.com>
Message-ID: <5747F02A.2010808@lsces.co.uk>
Date: Fri, 27 May 2016 07:58:50 +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: <37377d3b-827a-4cfd-580b-e33862084ab6@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: lester@lsces.co.uk (Lester Caine)

On 26/05/16 22:36, Rowan Collins wrote:
>> So every time I update the current tree because the client has selected
>> a different initial root I have to destroy perhaps 30 person objects and
>> rebuild the whole lot again from scratch?
> 
> In a word, yes: if you have a different set of data, use a different set
> of objects to hold it.
> 
> Objects are not memory slots to be re-filled, they represent a specific
> instance of a thing. Creating and destroying 30 objects on a modern
> system is the work of nanoseconds, and not something to be avoided at
> all costs.

There we will have to disagree!

And much of the reworking of the core operations of PHP7 was to remove
the unnecessary transfer of data from one area of memory to another to
get the speed up. It is also in my book why PDO has not solved the
problem of handling data properly either.

Now it may be that completely stand alone PHP applications using nothing
else do require a different mindset, but once one adds using a database
as the persistent data layer some things are better done in other ways.
My example of genealogical data covers the vast majority of what is
needed to create any web based application and the problems that current
thinking in how PHP should evolve are creating.

I can run PHP to individually access every member of the family tree
with individual database reads ... or I can produce a CTE query that
returns all of the data in one hit. The results of that read are an
already populated associative array of data. In an ideal world every
element would be a fully typed and constrained variable and in early
PHP5 days the recommendations were to use hashes of variables rather
than individual 'var' properties as it made management more 'OO' like.
Now things seem to have swung full circle and hashes are out and we need
individual properties/variables again but of this new 'much more robust'
style? And strict typing is supposed to be better.

I get that 'var' needed to evolve to add accessibility and would ideally
benefit from a level of typing, but where ever that var is used should
work exactly the same way and one should be able to simply use a
$[id][date_of_birth] DateTime element as if it was simply a constrained
scalar variable. My major hate with genealogical data is having to make
sure that the dates and times are the same. Translating European
material which has been 'reformatted' to use American date style IS
something to be avoided at all costs and can add orders of magnitude to
processing time while storing the results as a simple integer eliminates
all of that processing. But even then one can't be sure if one is using
the same 'type' of second :(

Having accessed the data which naturally includes many null elements is
it REALLY more efficient then to create new copies of all of that material?

-- 
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