Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93911 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19204 invoked from network); 12 Jun 2016 13:04:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jun 2016 13:04:04 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@mindplay.dk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@mindplay.dk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.53 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.213.53 mail-vk0-f53.google.com Received: from [209.85.213.53] ([209.85.213.53:32897] helo=mail-vk0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A4/90-12403-1CD5D575 for ; Sun, 12 Jun 2016 09:04:01 -0400 Received: by mail-vk0-f53.google.com with SMTP id d185so25093631vkg.0 for ; Sun, 12 Jun 2016 06:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mindplay-dk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6FrkqyAA/vsT7sD5t+jSPg9Vt4TtZVJh2SDS5GIPOo0=; b=Vclx8APrc6x6YmAQZJXy04j9WWSvnhnzl8W8BLgSXxf4rfeVUsxzN7BCSwHv68tPfW 7UY6N1iFpfU/Ml9aGkrDu5sH9HCPMYezeAVZ+O3Q7Bx15c5wwPDQQRjeg0Ny5S9zSL1g LA3nUuj2VpHcvxkv8OH1hP/ZZP9FOXkS3/xUz5xdq0MK5/IW9MQPVA8LHT5MbGzrAzlx K61i5uoPnlWze6prOnFj7ozeoUKZ+yJvG58ONZGL7Dhs84EEGjOIHo+pB0nQSgG8PbBa iRFmtck6C6LqAXu2R8b+6Igc3EgLhp+gaBwtsD/R/IbTRbxL8DTdwlxTXZYCW9QCeobi Jciw== 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:from:date :message-id:subject:to:cc; bh=6FrkqyAA/vsT7sD5t+jSPg9Vt4TtZVJh2SDS5GIPOo0=; b=WgDvfwchIC2EldHPt5DnDT48IW6utCV1PwIcTuCTKc+oWJyhCesuZWbL/EGC1nx9bE Q6SJIBKsOlblSEXyqdFJOZaDdeYVqF+BuxrluD9DyDMWzdAaHcxvQQ8QSP9/TtBMcZBe 0xSzbv+bJbkkQTwTsMAkDSZOXHxz6G0exSejWKw2l3SUMWN2tyV7Ot3Zr59JdxQ8Aseb /FoEZOji+o06G14K78tgUywzHfDBaoB1X7xp6HlGLX+/gh35sCzrmZ7dP0NP2fGY8jJB 3l3ie786H/vb2ms+g600FQSv0irhgjUlHW+7xOj238g5La86f+DrqORRQUYAGAs6P8cc iX7w== X-Gm-Message-State: ALyK8tJhJl+YIvfSZ38BAXVippr+sEo4FTmMXNJ0xBqWtr2LatwvwwsLOHYkh8DzRbt8pGyPzdbU+jOX8BrOqA== X-Received: by 10.31.61.196 with SMTP id k187mr4495808vka.43.1465736638582; Sun, 12 Jun 2016 06:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.88.148 with HTTP; Sun, 12 Jun 2016 06:03:57 -0700 (PDT) In-Reply-To: References: Date: Sun, 12 Jun 2016 15:03:57 +0200 Message-ID: To: Yasuo Ohgaki Cc: Dmitry Stogov , Joe Watkins , PHP internals , Phil Sturgeon Content-Type: multipart/alternative; boundary=001a114dc4fead6967053514675a Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: rasmus@mindplay.dk (Rasmus Schultz) --001a114dc4fead6967053514675a Content-Type: text/plain; charset=UTF-8 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 === "price") { if (!is_int($value)) { throw new UnexpectedValueException("..."); } $this->_price = $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 code > (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 solution > for this kind of problem. i.e. Validate fully during development, do > 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 > > --001a114dc4fead6967053514675a--