Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91779
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: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
 <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
 <56EC69EF.1090003@fleshgrinder.com> <56ECCFCB.6090105@garfieldtech.com>
 <56ED28BD.4040900@fleshgrinder.com> <56ED2FCB.6030609@lsces.co.uk>
 <56ED31BD.50307@fleshgrinder.com> <56ED36A6.4090201@lsces.co.uk>
 <56ED4363.8030908@fleshgrinder.com> <56ED460F.7060507@lsces.co.uk>
 <56ED46B7.2070409@fleshgrinder.com>
Message-ID: <56ED56B9.6010500@lsces.co.uk>
Date: Sat, 19 Mar 2016 13:40:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <56ED46B7.2070409@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: lester@lsces.co.uk (Lester Caine)

On 19/03/16 12:31, Fleshgrinder wrote:
>>> You are mixing to things like I did. If you never unset and never assign
>>> >> then the value of the property is *null* or as I defined to avoid
>>> >> confusion *void*. All fine. The question was, should this result in an
>>> >> error and the general consensus here is /no/.
>> > 
>> > My point is that $object->property = null; after the object has been
>> > 'constructed' is still a valid assignment ... the object's content may
>> > well be changed by changing the loaded object id.
>> > 
> I am not so sure about that and one could always reside to not using
> type hints in such situations. Additionally I do not think that one
> should change the /loaded object id/ better create a completely new
> instance. But I might be missing more context here.

This may well be where my own problem comes into play. TRADITIONALLY you
simply cached an array of data and used the object to view and
manipulate each record in the array. Even today that stage has not
changed as we STILL do a single database access to grab the material.
But the idea of then creating 'new instances' of each item seems
overkill if all one is doing is manipulating the data to present a
particular view of it. All of the overhead even of 'typed properties'
does little to improve the results but rather adds excessive work to
data which in a read only mode has already been fully validated. It's
only when one goes to edit a record that the need for more refined
validation comes in, and validating then occurs in the context of the
data, not simply if it's a number or string. In the good old days one
would simply load a script that contained the functions necessary for
the job rather than loading all of the potential code relating to the
object and constructing an 'instance' to then apply a new date of birth
or event.

The way everything seems to be moving is that the 'application' will be
fully compiled and cached before you ever use it, in order to compensate
for all the extra code which will actually never be used by a large
section of the clients base. Auto-loading everything just on the off
chance it may be used is not progress in my book.

-- 
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