Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63306 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88900 invoked from network); 9 Oct 2012 15:03:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Oct 2012 15:03:16 -0000 Authentication-Results: pb1.pair.com header.from=nathan.bruer@starin.biz; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=nathan.bruer@starin.biz; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain starin.biz from 72.51.41.225 cause and error) X-PHP-List-Original-Sender: nathan.bruer@starin.biz X-Host-Fingerprint: 72.51.41.225 unknown Windows 98 (1) Received: from [72.51.41.225] ([72.51.41.225:38869] helo=mail.starin.biz) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EB/4A-23861-1BC34705 for ; Tue, 09 Oct 2012 11:03:14 -0400 Received: from 173-167-160-145-illinois.hfc.comcastbusiness.net ([173.167.160.145]:64304 helo=NathanBruerHP) by mail.starin.biz with esmtp (Exim 4.80) (envelope-from ) id 1TLbEc-0002mD-FX for internals@lists.php.net; Tue, 09 Oct 2012 09:56:39 -0500 To: References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local> In-Reply-To: Date: Tue, 9 Oct 2012 09:56:22 -0500 Message-ID: <029b01cda62e$402f4ac0$c08de040$@starin.biz> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKuvN+PNJCtCrXYxUXlT5nsyCxNyAHwnPiLAZlt+S+V0o3CoA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mail.starin.biz X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [0 0] X-AntiAbuse: Sender Address Domain - starin.biz Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1 From: nathan.bruer@starin.biz ("Nathan Bruer") Is there a reason why we cannot implement this using PHP's already = widely used function syntax: class TimePeriod { private $Seconds =3D 3600; public $Hours { public function get() { return $this->Seconds / 3600; } private function set($value) { $this->Seconds =3D $value; } /*public implied */function isset(){ return isset = ($this->Seconds); } private function unset() { unset ($this->Seconds); } } } This would be much less confusing as it follows other PHP standards for = creating functions and such. I know C# has a similar syntax to what is = proposed, but we are not developing for C# we are developing for PHP = which has its own syntax rules that differ from C#'s and my vote is to = follow PHP's already in existent syntax format. --- -Nathan Bruer -----Original Message----- From: ekneuss@gmail.com [mailto:ekneuss@gmail.com] On Behalf Of Etienne = Kneuss Sent: Tuesday, October 09, 2012 8:15 AM To: Nikita Popov Cc: Clint Priest; internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 Hi, On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov = wrote: > On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest = wrote: >> It's been a while since I posted any updates about this, a few = individuals have been asking about it privately and wanting me to get it = out the door for PHP 5.5 release. It's come a long way since the last = time I posted about it. >> >> RFC Document:=20 >> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented >> >> Example Usage: >> >> class TimePeriod { >> private $Seconds =3D 3600; >> >> public $Hours { >> get { return $this->Seconds / 3600; } >> set { $this->Seconds =3D $value; } >> isset { return = isset($this->Seconds); } >> unset { = unset($this->Seconds); } >> } >> } >> >> Changes / Updates >> >> * isset/unset accessor functions now implemented (object & = static context, auto implementations, etc) >> >> * static accessor now fully functional >> >> * Reference functionality validated, tests written >> >> * All operators have been tested, tests written >> >> * read-only and write-only keywords: Added explanation of = reasons for inclusion at the top of the appropriate RFC section >> >> * Tested for speed, approaches or meets __get() speed. >> >> Internally things have changed quite a bit >> >> * cleaned up and simplified >> >> * had been using 4 to 5 additional fn_flag slots, now down to = two (READ_ONLY and WRITE_ONLY) >> >> * the automatic implementations now compiled internal php = code, this greatly simplified that part of the code and future proofed = it. >> >> The code is available at the url below and is up to date with master, = all tests pass. >> https://github.com/cpriest/php-src >> >> I'd like to get this project wrapped up in time to make it to the 5.5 = release, only a few things remain to be completed/updated: >> >> * Check on reflection code written prior to major changes = (tests still pass) >> >> * Add a few more reflection functions that were requested >> >> In total there are 79 tests for this new functionality, if there are = any others that I have missed, please let me know. > > What concerns me with the current implementation is that it leaks many = > implementation details, in particular the fact that the accessors are=20 > implemented as *real* __getXYZ methods and automatic implementations=20 > also use *real* $__XYZ properties. > > A few examples: > > ## 1 - __getProperty() method directly callable > > class Test { > public $property { > get { return 123; } > } > } > > $test =3D new Test; > var_dump($test->property); // int(123)=20 > var_dump($test->__getProperty()); // int(123) > > ## 2 - __getProperty() method exposed via exception > > class Test { > public $throwingProperty { > get { throw new Exception; } > } > } > > (new Test)->throwingProperty; > > exception 'Exception' in /home/nikic/dev/php-src/t29.php:9 Stack=20 > trace: > #0 /home/nikic/dev/php-src/t29.php(31): Test->__getthrowingProperty() > #1 {main} > > ## 3 - Can directly access $__automaticProperty and even unset it=20 > (causing notices in the internal code) > > class Test { > public $automaticProperty { > get; set; > } > > public function getAutomaticProperty() { > return $this->__automaticProperty; > } > > public function unsetAutomaticProperty() { > unset($this->__automaticProperty); > } > } > > $test->automaticProperty =3D 'foo'; > var_dump($test->getAutomaticProperty()); > $test->unsetAutomaticProperty(); > var_dump($test->automaticProperty); > > string(3) "foo" > > Notice: Undefined property: Test::$__automaticProperty in=20 > /home/nikic/dev/php-src/t29.php on line 13 NULL > > =3D=3D=3D=3D=3D > > I feel like this approach to the implementation will be a big can of=20 > worms. Sure, it works, but it is rather fragile and the enduser ends=20 > up dealing with internal stuff which he ought not care about. I think=20 > it would be better to cleanly separate out the accessor=20 > implementation. It might require more code now, but will be better in=20 > the long run. > I disagree, to me that this feature is all about syntactic sugar, as = such it does what it expected: it generates concrete properties and = methods that are somewhat hidden to the end-user. I feel that any implementation that do not rely on proper = properties/methods would be a big hack. Best, > Nikita > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,=20 > visit: http://www.php.net/unsub.php > -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, = visit: http://www.php.net/unsub.php