Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91753 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58109 invoked from network); 18 Mar 2016 20:39:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2016 20:39:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=leedavis81@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=leedavis81@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender) X-PHP-List-Original-Sender: leedavis81@gmail.com X-Host-Fingerprint: 74.125.82.41 mail-wm0-f41.google.com Received: from [74.125.82.41] ([74.125.82.41:35144] helo=mail-wm0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/02-42473-2876CE65 for ; Fri, 18 Mar 2016 15:39:30 -0500 Received: by mail-wm0-f41.google.com with SMTP id l68so44315500wml.0 for ; Fri, 18 Mar 2016 13:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DELEiVSy7BYWpHn6g0wTJmlehGsgLdgDTckRWAfPMno=; b=AorqOOxxcKKnh+vq+1jzfTPL4rKvj7d/vEVCQ4N5VGAFSvc5/Pf4QOlwSOGkGUHxUy 1TgrkBfIYBZB4BXXrPzNOhQVQhlh/asQEF6k0m0u/dWoEKWhDwR3jJ9+3XRxH4cZwETX rSi/XymaWQHzBvym5j/hDpW5INZAPtR1DCgB4fEO7JgZYPGrhtKk68fzFBtJNE1EqwPV WW40fBka6anrRVHHlFjmV6y2UoCUesGyLx44bWOK5AZZ1NQjrsVZ2+y56+HrD6U4CzZL iCUJOQuPXAHj9V/h7n2tYBQUpwe7W1VDWzmuTjQ0VNknlt5nXoy36m4ZZUF10AI8uKFE pgUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DELEiVSy7BYWpHn6g0wTJmlehGsgLdgDTckRWAfPMno=; b=A9CAfe7fJS654PVggarn+oMc0kNl/22+YxrJKqB5gTMAeyj6FESXjPEIKQiYAwP4M5 47Qq4MqX27CGIci65sUYnhshEqZc51ckG8zy1jPt/y8w9g7uo/hXQP9/qIB/nMhdLf+R 7hSZRrsdfbFNvOAfJXtAjSejXtGgkuzyPyYpYxV4BM9DWaRsAsA7w/QPOg9Uo9sZ2q1n 4x29eG6y2DevGjohhjQMQYwFqGyGe/wTrPEh8Sh3lmJqNfsnvN4jQ7sneMHC54Xw0/0b k5SIkGiHO7+kvxR47cDJ5W/ktcHFnIosgV6waJdN6ZZIdrMvOLnwhaFyH5v9EpVSzCNP w61A== X-Gm-Message-State: AD7BkJJGcFn6Hj2Ichb3aSd+WyrGhKSk1pSwM1ETTi779W2zDFRnLqf5krRCUma/IU3YWAiT+Gh35CUiadqLkQ== MIME-Version: 1.0 X-Received: by 10.28.225.198 with SMTP id y189mr1317107wmg.94.1458333567651; Fri, 18 Mar 2016 13:39:27 -0700 (PDT) Received: by 10.28.222.3 with HTTP; Fri, 18 Mar 2016 13:39:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Mar 2016 20:39:27 +0000 Message-ID: To: Phil Sturgeon Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a114b0c884395b3052e58bebb Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties From: leedavis81@gmail.com (Lee Davis) --001a114b0c884395b3052e58bebb Content-Type: text/plain; charset=UTF-8 Hi all, first up, major thanks to both Joe and Phil for putting this together. I'm fully behind the concept of typed properties and think it would be a great feature to have in the language. I have a few points I'd like to make on the current implementation being proposed. 1) There's an issue with the way the __get magic method works. I understand this has been introduced from allowing unset on typed properties (because of the reasons Marco mentioned previously), however it's still something I feel needs addressing: class Foo { public int $bar; public function __get($name) { return 123; } } $foo = new Foo(); unset($foo->bar); var_dump($foo->bar); // int(123) $foo = new Foo(); var_dump($foo->bar); // Fatal error: Uncaught TypeError: Typed property Foo::$bar must not be accessed before initialisation I'd consider the fact that var_dump($foo->bar); produces different things here a bug. They're both unset/uninitialised and should produce the same result. Which in my opinion should be "int(123)", but i'll get onto that in a bit. 2) Having a guarantee that a variable is of a certain type has a ton of benefits, mostly that you don't have to add defensive code to check its type. As Larry pointed out, littering your code based with !is_null() is not a nice thing to have to do. Unfortunately typed variables will at some point be uninitialised. you can't really force the developer to set them (either at construct or later) as this is something that should in my opinion always belong at implementation and not baked in/forced at the language level. With this in mind, handling uninitialised state will always be a thing that needs to be done. We can't really guarantee that the property was set up properly, or start to return a default value of said type. Further to this, and the fact that the ability to unset typed properties has been reintroduced it now becomes possible to initialise a property, have it unset and get TypeError's on subsequent access (where no __get() is provided). So even after initialisation we can never be 100% sure a property hasn't been destroyed and contains the type you'd expect. As it doesn't appear there's any way we can actually provide this guarantee. I'd suggest removing TypeError's on access as it's superfluous. This would then solve my first point as the magic method would be called as expected. I know this isn't ideal, but the type check on set is still very powerful and still provides a guarantee that you have either an uninitialised property, or a one of a type you'd expect. 3) One final small point; it would be great if we could also have typed properties outside the scope of a class. Not a show stopper by any means, but certainly a nice to have. That's all. Again thanks so much for putting this together. Lee /@leedavis81 On Wed, Mar 16, 2016 at 4:36 PM, Phil Sturgeon wrote: > Hello everyone, > > I have completed the draft for an RFC, to add Typed Properties. The > patch has been written by the one and only Joe Watkins. > > https://wiki.php.net/rfc/typed-properties > > I would really appreciate constructive feedback on this RFC, with a > few areas especially: > > 1. How scared are we that integers can be expanded to floats on runtime? > > 2. This whole temporary nullability situation, where unset properties > will error on attempted usage if not set. Should they instead error > after the constructor has been called if they are still not holding a > value? > > 3. Weak vs Strict. Right now this is entirely strict, with no > declare() to change mode. Reasons for this vary, from various sources, > but include "Not sure how to implement it" and "Well people should not > be using properties as part of their public API". > > Help on 3 would be appreciated. > > Also let's please avoid "PHP IS TURNING INTO JAVA" and the other > rather common rhetoric. Strict Type Hinting might have been seen as a > battleground for fans of strict and fans of weak to fight through a > keyboard, but this RFC will not be the repeat. > > We'll have a nice, orderly, constructive conversation about this RFC, > and improve the patch as you all provide feedback. > > Let me know what you think folks! > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --001a114b0c884395b3052e58bebb--