Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103238 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60624 invoked from network); 23 Sep 2018 23:25:19 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.203) by pb1.pair.com with SMTP; 23 Sep 2018 23:25:19 -0000 Received: (qmail 2601 invoked by uid 89); 23 Sep 2018 19:32:45 -0000 Received: by simscan 1.3.1 ppid: 2593, pid: 2597, t: 0.0637s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 23 Sep 2018 19:32:45 -0000 To: PHP internals References: <5273905.aE8IdBJUB6@vulcan> Message-ID: <770f7637-85c7-936b-a007-9a212e67987a@lsces.co.uk> Date: Sun, 23 Sep 2018 20:32:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2 From: lester@lsces.co.uk (Lester Caine) Wrong reply button :( On 23/09/2018 07:18, Rasmus Schultz wrote: >> That is the entire point of the elephant analogy: that knowing what can > get in doesn't necessarily mean knowing what is already inside - BUT, > knowing what can get in may still useful in itself. > > I understood that, and I disagree - just knowing what can get in is not > useful or interesting in itself. It's not even a new language feature - you > can already achieve the same with a simple setter. It's just new syntax. > > The only reason it's interesting to control what can get inside with type > hints, is to enable the language to do something new - something it > couldn't already do, which is to guarantee that the type enforces it's own > state specification. > > I understood the analogy, and I don't agree. In other words it's yet another bodge to add strict typing without properly addressing the real problem. Adding 'types' to properties only covers the properties that are supplied via that interface? I think that is what is being proposed here? Internally the object may have other variables that depend on the supplied properties, or be populated from another interface such as a database in my case. THOSE variables need to be managed in the same way as properties, and magic code like setters or PROPER handling of variables is needed to ensure that the variables are suitable TO initialize a variable. All these little patches to making PHP strict STILL need all of the old code to validate that the data is actually usable! PLEASE can we get back to making variables manage their own VALIDITY rather than just some arbitrary concept of type! -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk