Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93619 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93735 invoked from network); 29 May 2016 07:28:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 May 2016 07:28:50 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:47872] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 24/20-23584-F2A9A475 for ; Sun, 29 May 2016 03:28:48 -0400 Received: (qmail 21596 invoked by uid 89); 29 May 2016 07:28:44 -0000 Received: by simscan 1.3.1 ppid: 21589, pid: 21592, t: 0.0901s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 29 May 2016 07:28:44 -0000 To: internals@lists.php.net References: <20160525215208.034FC1A801B3@dd1730.kasserver.com> <5fd54aa0-4fdf-c1e7-eae8-765aa89c8498@fleshgrinder.com> <08963b03-8394-6d62-4e5b-393f3fcb5647@fleshgrinder.com> <9e9db70d-d72d-d93e-0c81-18c2aa228618@gmail.com> <409002d8-b5e3-5990-7358-246adc7e3cab@fleshgrinder.com> <57474A08.80807@lsces.co.uk> <6f7403b6-bf22-a12b-dfb2-43fe82983e7d@fleshgrinder.com> <57474F9C.6080104@lsces.co.uk> <1733cfce-001b-1079-e929-88f7dde0f2dd@gmail.com> <57475F27.3090306@lsces.co.uk> <34edcbd1-2d6a-cd52-7bbb-c393ab62d32d@gmail.com> <574772BA.3030305@lsces.co.uk> <5748164C.7020803@lsces.co.uk> <5156d2d3-6c7b-b5d0-fdfd-9064d8fb1d58@fleshgrinder.com> <0B6AA77E-C201-4EC4-98DB-EED5436DCF69@gmail.com> <54ce74f9-946f-2277-8328-050af03ed3d8@fleshgrinder.com> <5749516A.8080807@lsces.co.uk> Message-ID: <574A9A2C.8080200@lsces.co.uk> Date: Sun, 29 May 2016 08:28:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5749516A.8080807@lsces.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: lester@lsces.co.uk (Lester Caine) On 28/05/16 09:06, Lester Caine wrote: > 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 :) Adding that 'var' seemed totally natural as I wrote it. I could not understand why at the time, but having slept on it, the reason has is obvious. 'DateTime' can't be 'null' and any attempt to set it to such will give you 'now' instead. BUT we have demonstrated (hopefully) that we do need null dates, so we need a container that can either be null or a date ... sounds suspiciously like good old var? Now access to 'var' needs an attribute which can be 'public,private,protected' .. . but also 'read only' ( I'll ignore 'write only' because in my book that is part of the access level - public read - protected write? ). The key element here is that if var is a 'read_only' DateTime we don't need all the crap of DateTimeImmutable and Derick's attempt at adding 'mutability' to the original dateTime class would probably not have existed? The key I think here is IF 'var' has been initialized and that depends on - perhaps - if the type not_null is true. const comes to mind here as well and a const var DateTime $start; Would give you a fixed snapshot time HOPEFULLY you already see where this is going ... Attributes such as __type, __limit, __length, __enum apply to the var and are then used to ensure that the created value is valid. Just to complete the picture in my archaic working practice... public var $root_person $root_person->__type( Person, not_null = false ); $root_person->__init( id1 ); Would have a value of an associative array of the data for 'Person' consisting of the list of fully typed and constrained 'var' items. The CODE for Person would simply work on the pointer to that hash. Which is why I think I'm getting mixed up over the difference between the array view of a value and the object view. In PHP they used to be interchangeable but now things like this RFC are making them something different? -- 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