Re: [RFC][Vote] Typed Properties
| From: | Fleshgrinder | Date: | Thu, 26 May 2016 19:16:40 +0000 |
| Subject: | Re: [RFC][Vote] Typed Properties | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93582@lists.php.net to get a copy of this message | ||
On 5/26/2016 9:10 PM, Lester Caine wrote:
> DateTime is probably a better example to work with than 'int' since it
> already has a long pedigree of problems and clashes where many projects
> had their own interpretation and still use their own version of the
> class. My problem with '\DateTime $d' is that by default it returns
> 'now' rather than an 'empty/null' value in which to put the data from
> the database. I can't create a 'null' version of DateTime so one has to
> have a phantom date simply to ensure you know if it has been initialized
> with your own data later - or continue to use the older user space classes.
>
> It is handling just how the variable/property is initialized that is the
> whole problem here and there may be very good reasons that the
> initialization is later then the 'construct' be that a DateTime or an
> int ... null is the correct way of indicating that 'as yet we do not
> have the value of type xxx' just as it does for an untyped value, so
> trying to make a special case to block it's use is simply strangling
> normal usage in other cases?
>
Could you come up with some example code of what you cannot achieve? I
cannot think of a single situation that is valid and not a developer
error which would be impossible with the currently discussed approach.
--
Richard "Fleshgrinder" Fussenegger
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc