Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67253 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44333 invoked from network); 1 May 2013 17:13:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 May 2013 17:13:19 -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.220.174 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.220.174 mail-vc0-f174.google.com Received: from [209.85.220.174] ([209.85.220.174:32778] helo=mail-vc0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/B1-28617-D2D41815 for ; Wed, 01 May 2013 13:13:18 -0400 Received: by mail-vc0-f174.google.com with SMTP id hf12so1427892vcb.33 for ; Wed, 01 May 2013 10:13:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=RPqZox4ryxqN1suD0i23X3bP5XSUyGS1f+dUYWd8YOE=; b=h/YHjhvvArZx/1A38uJY0HJkhG6rErvg5RnThTkLyLItXghYiejASMwwDxXbyniO62 YaUCFhV7d0Gfk7EwHj/ZySPLAOqEOJhTbDRkCM6C9R+BfwgPLlKFLEb8HgJZ1Yn1457m fRYHknUCIPUSU6MTUXIoMmIi0xsFT66B4IyXh1izm2NS12Gd5fm1OBwHi9eIP/vldYRL AMxlLcWkZYTnw++SeJ9ZVRgJmMaYE6//V/ZDTs8qabyq+xFLRgT24aJfkEBpfnB0uETC /wBWiNg4vzaAPA7jd6pRoSAhtTZPBF40FNiO9PN5zL3Eosl2dN9Ck7Isn2ESZSnG9yKZ UfxA== MIME-Version: 1.0 X-Received: by 10.220.89.198 with SMTP id f6mr1092465vcm.45.1367428395341; Wed, 01 May 2013 10:13:15 -0700 (PDT) Received: by 10.58.28.134 with HTTP; Wed, 1 May 2013 10:13:15 -0700 (PDT) In-Reply-To: References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> <51805A00.4050803@lerdorf.com> <5180652D.1080007@lerdorf.com> Date: Wed, 1 May 2013 13:13:15 -0400 Message-ID: To: Etienne Kneuss Cc: Rasmus Lerdorf , Stas Malyshev , PHP internals Content-Type: multipart/alternative; boundary=047d7b343b42c2aa6c04dbab3b1d X-Gm-Message-State: ALoCoQkbC4mqCMNPo6LcI6q7g9QY2mDRrgKKvjh+5o0lSIvVfXUOSw7DKNDJCk5teS5yfe7z9YGI Subject: Re: [PHP-DEV] property de-referencing From: rasmus@mindplay.dk (Rasmus Schultz) --047d7b343b42c2aa6c04dbab3b1d Content-Type: text/plain; charset=ISO-8859-1 > > The only reason being that the syntax "^$user->name" is "more static" than > new PropertyReference($user, 'name'), and thus easier to refactor? Not "more static", it is static - a string-based property-reference is not. Refactoring isn't the only benefit - of course most of the benefits are going to come from IDE support, but would include things like inline documentation, auto-complete and warnings/errors based on static analysis/inspections. I already covered that. PHP-based code-analysis tools would also be able to do a better job when checking views etc. - if you're using PHP-based static analysis tools to check for code-smells etc. there's a good chance you have it configured to skip your view-template folders... > To me they really look equivalent from a refactoring point of view. They are not. Refactoring based on strings is guesswork - it's slow when working with a large codebase, and it's error-prone, and therefore requires manual review of every change before you apply, even for things that should be quick/simple like renaming a property. In any case, as many already pointed out, this sounds like a lot of pain > for really little (if any) gain. Going to take a wild guess and say your IDE or text-editor does not do static analysis? Yes, there is little immediate gain from the feature itself - but as demonstrated, valuable long-term gain from being able to write simpler, stronger abstractions that provide more comfort and safety in an IDE. On Wed, May 1, 2013 at 10:24 AM, Etienne Kneuss wrote: > > > > On Wed, May 1, 2013 at 2:35 PM, Rasmus Schultz wrote: > >> > >> > This is a fringe feature, as evidenced by the fact that you >> > are having a hard time convincing people that it is needed >> >> >> As with anything that isn't already established and well-known, it's hard >> to convince anyone they need anything they don't understand - I think the >> barrier here is me having difficulty explaining a new idea/concept. That >> doesn't make it a fringe feature - I have already demonstrated by example >> how this would be useful in practically every mainstream framework. >> >> Properties simply don't carry >> > this information with them so a lot of things would have to change >> > internally for this to ever work >> >> >> I'm not sure what information you're referring to? >> >> Let's say for the sake of argument, I'm going to use a pre-processor to >> transform the following code: >> >> $prop = ^$user->name; >> >> var_dump($nameprop->getValue()); // => 'Rasmus' >> >> $nameprop->setValue('Bob'); >> >> var_dump($nameprop->getValue()); // => 'Bob' >> >> The pre-processor output might look like this: >> >> $nameprop = new PropertyReference($user, 'name'); // $prop = ^$user->name; >> > > > So basically you want to introduce syntactic sugar for: > > new PropertyReference($user, 'name') > > The only reason being that the syntax "^$user->name" is "more static" than > new PropertyReference($user, 'name'), and thus easier to refactor? To me > they really look equivalent from a refactoring point of view. > > In any case, as many already pointed out, this sounds like a lot of pain > for really little (if any) gain. > > >> >> var_dump($nameprop->getValue()); // => 'Rasmus' >> >> $nameprop->setValue('Bob'); >> >> var_dump($nameprop->getValue()); // => 'Bob' >> >> Only the first line changes - the rest behaves and runs like any normal >> PHP >> code. >> >> And the PropertyReference class could be implemented in plain PHP like >> this: >> >> class PropertyReference >> { >> private $_object; >> >> private $_propertyName; >> >> public function __construct($object, $propertyName) >> { >> $this->_object = $object; >> $this->_propertyName = $propertyName; >> } >> >> public function getObject() >> { >> return $this->_object; >> } >> >> public function getPropertyName() >> { >> return $this->_propertyName; >> } >> >> public function getValue() >> { >> return $this->_object->{$this->_propertyName}; >> } >> >> public function setValue($value) >> { >> $this->_object->{$this->_propertyName} = $value; >> } >> >> // and maybe: >> >> public function getReflection() >> { >> return new ReflectionObject($this->_object); >> } >> } >> >> >> You can see the above example running in a sandbox here: >> >> >> http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192bd3db84ddaf84c83 >> >> Someone said they didn't think this would work for accessors, so I'm >> including a running sample with a User model that uses accessors: >> >> >> http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd8e73ff80717f3cb >> >> Note that the dynamic User::$name property in this example is properly >> documented and will reflect in an IDE. >> >> >> On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf >> wrote: >> >> > On 04/30/2013 05:17 PM, Rasmus Schultz wrote: >> > >> > > If the asterisk (or some other character) offers and easier >> > > implementation path, whatever. >> > >> > It doesn't. This is a fringe feature, as evidenced by the fact that you >> > are having a hard time convincing people that it is needed, and thus >> > shouldn't overload an existing operator. Visually it would be confusing >> > to take any well-known operator and give it a different obscure meaning. >> > But yes, syntax-wise ^ could be made to work, the implementation problem >> > I referred to is lower-level than that. Properties simply don't carry >> > this information with them so a lot of things would have to change >> > internally for this to ever work and if a clean implementation could be >> > found, like I said, adding it to the reflection functions is the proper >> > place. >> > >> > -Rasmus >> > >> > > > > -- > Etienne Kneuss > http://www.colder.ch > --047d7b343b42c2aa6c04dbab3b1d--