Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94196 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38980 invoked from network); 22 Jun 2016 13:12:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jun 2016 13:12:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=michal@brzuchalski.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=michal@brzuchalski.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender) X-PHP-List-Original-Sender: michal@brzuchalski.com X-Host-Fingerprint: 188.165.245.118 ns220893.ip-188-165-245.eu Received: from [188.165.245.118] ([188.165.245.118:60901] helo=poczta.brzuchalski.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 55/3E-43024-6AE8A675 for ; Wed, 22 Jun 2016 09:12:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by poczta.brzuchalski.com (Postfix) with ESMTP id 490D6298420D for ; Wed, 22 Jun 2016 15:12:03 +0200 (CEST) Received: from poczta.brzuchalski.com ([127.0.0.1]) by localhost (poczta.brzuchalski.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cugJuq5H5EjX for ; Wed, 22 Jun 2016 15:12:00 +0200 (CEST) Received: from mail-qk0-f181.google.com (unknown [209.85.220.181]) by poczta.brzuchalski.com (Postfix) with ESMTPSA id EC0EE2984212 for ; Wed, 22 Jun 2016 15:11:55 +0200 (CEST) Received: by mail-qk0-f181.google.com with SMTP id p10so63433770qke.3 for ; Wed, 22 Jun 2016 06:11:55 -0700 (PDT) X-Gm-Message-State: ALyK8tKil+w6mY550j7z9h0Z8kzo7N27mnYVyf4iZaO2jK9LVIKkZshB5Y36jwU9iqmdEPI4e5qrmB32DmdgeQ== X-Received: by 10.55.166.3 with SMTP id p3mr35798158qke.161.1466601115027; Wed, 22 Jun 2016 06:11:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.129 with HTTP; Wed, 22 Jun 2016 06:11:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jun 2016 15:11:53 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Marco Pivetta Cc: Philip Sturgeon , Yasuo Ohgaki , Dmitry Stogov , Joe Watkins , PHP internals , Rasmus Schultz Content-Type: multipart/alternative; boundary=94eb2c06ea747d12970535ddaec1 Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=) --94eb2c06ea747d12970535ddaec1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, According to my knowledge this path doesn't implement only string and int types but whole of type hinting. So your example usage of string and int maybe is unneded 'additional' check, but in other cases where you expect objects which implements specific inteface or class it's huge advantage when on runtime PHP checks if specific property is set properly - has proper type. Proper typed 'var' sure could be implemented in userland by complex type checks in setters, but do we really need that setters/getters hell with lots of `is_a`, `instanceof`, `class_implements` checks? There's something I now for sure, observed this on voting for RFC's from some time - if this path will be voted no there won't be any RFC with same functionality in near future. IMHO people writing RFC's and implementing patches they will not wanted to provide another RFC's and another implementation. Regards, -- Micha=C5=82 Brzuchalski 2016-06-22 15:06 GMT+02:00 Marco Pivetta : > Top-posting due to mobile conn. > > I voted no due to flaws introduced in the language by the current RFC. > > The performance impact is irrelevant. > On Jun 22, 2016 11:38, "Micha=C5=82 Brzuchalski" > wrote: > >> Hi, >> >> I may don't have voting privileges but as an 10yr PHP development >> practitioner I can't believe that such big and awesome feature like Type= d >> Properties minimally can't have enought votes to be a part of PHP langua= ge >> (26/(26+16) =3D 62% and that's not enoght to 2/3+1vote). >> There are plenty of places where type hinting actually exists and looks >> like Typed Properties can be great complement of type system in PHP >> language with the ability to still be so dynamic language as it is right >> now. >> The impact of 0.1% (or even more) of performance IMHO should not have no >> significant meaning. >> Someone earlier wrote that properties types should be ensured by >> frameworks >> - but that doesn't never happen, the impact on performance while >> dynamically type checking inside setters would be few times greates than >> this patch impact. Not to mention the fact that the feature itself >> suggests >> good practice. >> Without it, we will still have setters/getters hell, and there will newe= r >> be safe frameworks instad there will always be some hack's inside >> subclasses or some other ways. >> Without it, PHP will newer be aqualed such as Java, C# even Hack languag= e >> - >> there still will continue to be a big gap, due to the lack of type >> hinting. >> Sure you could say start to code in Hack it has type safier system, it h= as >> generics, annotations and other features which from time to time are in >> PHP >> RFC's but most of time they are declined and Hack lacks of great IDE >> support like PHPStorm which I use and love because of refactor, code >> styling, run&debug etc. >> PHP language has poor type safety and IMHO without such patches it will >> never evolve into type safety programming language. >> >> Regards, >> -- >> Micha=C5=82 Brzuchalski >> >> 2016-06-13 11:40 GMT+02:00 Joe Watkins : >> >> > Morning, >> > >> > > This wouldn't affect the performance of untyped properties at all. >> > >> > There are extra instructions in that code. >> > >> > When the code you have is only 5 instructions, adding 1 more instructi= on >> > makes a 20% increase in instructions ... >> > >> > That is what we are looking at in these micro benchmarks; The number o= f >> > instructions is so small, that even the small difference is measurable= . >> > >> > Of course you can measure the difference, and obviously there are goin= g >> to >> > be more instructions, but we should only care about what effects real >> world >> > code. >> > >> > This doesn't effect real world code. >> > >> > Cheers >> > Joe >> > >> > On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz >> > wrote: >> > >> > > Pretend I know (basically) nothing about how PHP was implemented, >> because >> > > I don't ;-) >> > > >> > > But I don't understand why regular property updates should be >> affected by >> > > this at all? >> > > >> > > If I had to implement type-checked properties in plain PHP, I would = do >> > > something like this... >> > > >> > > /** >> > > * @property int $price >> > > */ >> > > class Product >> > > { >> > > private $_price; >> > > >> > > public function __set($name, $value) { >> > > if ($name =3D=3D=3D "price") { >> > > if (!is_int($value)) { >> > > throw new UnexpectedValueException("..."); >> > > } >> > > $this->_price =3D $price; >> > > return; >> > > } >> > > throw new RuntimeException("undefined property {$name}"); >> > > } >> > > >> > > public function __get($name) { >> > > return $this->{"_{$name}"}; >> > > } >> > > } >> > > >> > > I would have guessed an implementation of type-checked properties >> would >> > > work in much the same way. >> > > >> > > Of course, it wouldn't use "_" as a prefix for the underlying >> property, >> > > but some other magic byte, much like how private properties are >> > internally >> > > prefixed with a magic byte, right? >> > > >> > > This wouldn't affect the performance of untyped properties at all. >> > > >> > > Of course typed property writes would be more expensive, but that's >> to be >> > > expected. >> > > >> > > >> > > On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki >> > wrote: >> > > >> > >> Hi Dmitry, >> > >> >> > >> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov >> wrote: >> > >> > I hardly worked on implementation of this patch for a week, but I >> > still >> > >> don't like it. >> > >> > >> > >> > It makes 15% slowdown on each property update in existing PHP cod= e >> > >> (without types), and I don't see a way to improve this. >> > >> > >> > >> > Update of typed properties is going to be even more expensive. >> > >> > >> > >> > Benchmark results are included into RFC (and not changed with the >> > >> latest version of the patch). >> > >> > >> > >> > >> > >> > -1. >> > >> >> > >> If we are concerned about performance, DbC would be the only soluti= on >> > >> for this kind of problem. i.e. Validate fully during development, d= o >> > >> minimum validation on production. DbC helps type inference also. >> There >> > >> may not be enough time for discussion, but do you think there is >> > >> enough time for implementation? I suppose implementation is >> > >> straightforward, so it might be OK to have RFC w/o implementation. = We >> > >> have 2 options anyway. It's waste of time for having 2 >> > >> implementations. Would you like to proceed the RFC for 7.1? >> > >> >> > >> Regards, >> > >> >> > >> -- >> > >> Yasuo Ohgaki >> > >> yohgaki@ohgaki.net >> > >> >> > >> -- >> > >> PHP Internals - PHP Runtime Development Mailing List >> > >> To unsubscribe, visit: http://www.php.net/unsub.php >> > >> >> > >> >> > > >> > >> >> >> >> -- >> pozdrawiam >> -- >> Micha=C5=82 Brzuchalski >> > --=20 pozdrawiam -- Micha=C5=82 Brzuchalski --94eb2c06ea747d12970535ddaec1--