On 27/05/16 19:03, Fleshgrinder wrote:
>>> 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.
>> >
>> > Actually, that's one of the points up for discussion: should accessing
>> > the property when no assignment has been made raise an E_NOTICE, so that
>> > there is a difference between "?int $foo" and "?int $foo = null".
>> >
>> > Regards,
>> >
> True, I forgot and I am in favor of E_NOTICE. This was actually part of
> my super confusing long example.
Back peddling a bit and looking forward ...
Ideally people would prefer for OO convention that properties are all
protected and only accessed via magic getters and setters? As per Ryan's
example. So
class Person {
protected ?DateTime $death;
any access to the properties is contained within the class. I still
think here that ADDING the '?' to restore default actions is the wrong
way around, but can't see an easy way of flagging 'not null' instead?
I think that moving on from this where *I* have been using associative
arrays for properties, this new element of typing does not work, and
that I have to move back to the 'array' being the list of typed
properties in the class? Which requires that every used property is
defined, while the results set from a database lookup is more flexible
than that ... which is why the switch was TO associative arrays for
properties in the classes. We even have generic code for getting and
setting array elements and the array is protected.
Most of you here are of the opinion that everything must be defined and
typed beforehand for good coding practice and I do accept that - EXCEPT
having defined everything the null state becomes more important when
sections of that data is not available. In my working practice it is
better that at run time one only creates all the magic around every
property if those properties are actually returned in the result set.
This may be wrong, but if I have created a validated and constrained set
of data in the database read, there should be no need to further
validate it? And my 'empty objects' are the structure of types and
constraints I need to manage input of new data.
I know you do not like me mixing up discussions, but the 'attribute'
debate is tightly woven with this if the documentation is providing the
type flag. I have all of that in either docblock or SQL schema and so I
THINK what I am looking for is
class Person {
protected var $death; // var is intentional - my flag for a holder
$death->__type( DateTime, not_null = false );
To which one can add
$death->__limit( $birth, '120years' );
Where $birth now has to be the same type and '120years' gets magically
converted to a date offset :)
BASICALLY any hard coded handling of attributes can co-exist tidily with
the much more dynamic and flexible nature that PHP used to have! If you
want strict fully bolted down code simply use C/C++ in the first place?
--
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
