On 13/09/16 00:47, Stephen Reay wrote:
> Regarding identity, I’m going to refer back to the DateTimeImmutable class. I
> know its not the same implementation, but honestly I don’t think that
> matters. Developers use PHP because they generally *don’t* have to worry
> about the internal details of the engine.
>
> e.g.:
> $d = new DateTimeImmutable();
> $e = $d->add(new DateInterval('PT0S'));
>
> var_dump($d === $e); // bool(false)
ReadOnly DateTimeStamp is the only 'objects' I can currently see a use
for in my own code base. CoW makes perfect sense to me but I would not
view that as 'clone', simply 'construct a new readonly object'. I've
already indicated that I view date/time as a simple 64 bit number, and
'comparable' fits that model nicely except it needs a more flexible
TOLERANCE for months. ( And DateTimeImmutable does not work for me but
that is because I have raw access to the firebird timestamps )
Just where else do people think 'immutable' objects are essential? Just
what is necessary over a 'readonly object'?
I'm still trying to get my head around some of the hidden details here.
My 'readonly object' assumes the code to handle is a separate class used
to view the data, but I assume the sort of object being discussed here
is in essence a 'constructionaless' copy of the class? With wriggle room
to perhaps make some write code available for some strange reason? I'm
still struggling to see just where the 'code' fits in this. If I have a
copy of the code in the 'construction' version of the class does the
copy also need that code duplicated?
--
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
