On 27/05/16 11:25, Fleshgrinder wrote:
> On 5/27/2016 11:41 AM, Lester Caine wrote:
>> Now I am confused, but it's probably because I'm looking at a simple
>>
>> $f->d = new DateTime( $initial );
>>
>> While you are looking at
>>
>> If ( isset($initial) )
>> then $f->d = new DateTime( $initial );
>> else $f->d = null;
>>
>> While the original code would have simply been
>>
>> $f->d = $initial;
>>
>> And in an ideal world, because $d has been typed as DateTime this would
>> magically run 'new DateTime($initial)' which is where I am stumbling
>> because *I* simply look at '?DateTime $d' as creating a DateTime object
>> where in fact $d is a different type of object which will then hold the
>> link to the real one. I am still looking for $d to be an object I can do
>> all of the checks on that are provided by int or DateTime as appropriate
>> ... the object needs to exist before the 'new' in order to know if you
>> need the first or second type of $initial code ... or we make typed
>> properties only work one way or the other?
>
> PHP does not automagically instantiate the DateTime object for you, this
> is still your responsibility. The type hint on the property only
> restricts what you are allowed to assign to the property, nothing else.
Hence the 'in an ideal world'! It is perhaps worth making clear that a
'typed property' element IS simply a holder for the pointer to the real
element while the untyped properties are the element themselves? The
differentiation of 'scalar' probably comes into play, but does that
result in untyped scalers having to have the overheads for adding the
type flags?
> It is true that PHP will coerce the value automatically if you are in
> weak mode but this is only true for scalar values and nothing else. Also
> note that you might not want that while working with a database because
> PHP might destroy your UNSIGNED BIGINTs without you noticing.
And 32bit builds mess things up as well ...
> class O {
> public ?DateTime $d;
> }
>
> if (isset($row['d'])) {
> $o->d = new DateTime($row['d']);
> }
>
> No need to assign null since it already is null by default and the
> nullable hint will not result in any errors upon accessing it.
With the proviso that $o is not used again ... currently all of my
object classes have a constructor for a blank object along with a loader
to 'initialize' the data. Empty objects such as 'father' can be
populated with data and saved, loaded with an existing record, or wiped
if incorrect associations existed ... allowing the correct data to be
added. AJAX allows things to happen within a page which in the past
would have been complete new page loads without any of the problems of
'cached' data?
> PS: The UNSIGNED BIGINT thing is one of the reasons why I want
> intersection and union types so that we can do the following:
>
> class O {
> private int|string $id;
> }
>
> And leave it to a more intelligent system to determine whether this can
> be safely converted to an int or not (e.g. MySQLi).
And the same thing applies to me except in relation to 32 bit or 64 bit
integers. Many legacy systems still use 32bit id's while all of my new
systems use 64bit ones. So int32 and int64 is one requirement which int
does not allow. On the SomeModel example the type of ['id'] is provided
by ADOdb and I can check if I need to handle the problem or not. If the
$row['id'] was correctly typed a lot of additional checks would be
eliminated, but the safe way of passing these id's IS as a string rather
than an integer.
--
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
