Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67262 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67679 invoked from network); 1 May 2013 21:39:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 May 2013 21:39:17 -0000 Authentication-Results: pb1.pair.com header.from=rstoll@tutteli.ch; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rstoll@tutteli.ch; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender) X-PHP-List-Original-Sender: rstoll@tutteli.ch X-Host-Fingerprint: 80.74.154.78 ns73.kreativmedia.ch Linux 2.6 Received: from [80.74.154.78] ([80.74.154.78:50234] helo=hyperion.kreativmedia.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8B/55-28617-28B81815 for ; Wed, 01 May 2013 17:39:16 -0400 Received: (qmail 12223 invoked from network); 1 May 2013 23:39:12 +0200 Received: from ip-31-205-11-203.ask4internet.com (HELO RoLaptop) (31.205.11.203) by ns73.kreativmedia.ch with (AES128-SHA encrypted) SMTP; 1 May 2013 23:39:12 +0200 To: "'Etienne Kneuss'" , "'Rasmus Schultz'" Cc: "'Rasmus Lerdorf'" , "'Stas Malyshev'" , "'PHP internals'" References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> <51805A00.4050803@lerdorf.com> <5180652D.1080007@lerdorf.com> In-Reply-To: Date: Wed, 1 May 2013 22:39:12 +0100 Message-ID: <000f01ce46b4$52746360$f75d2a20$@tutteli.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJH2Xu/ms45cks5g1geQvJz9rTAtQDV0/wKAYbXjrwB4fJnaQMQ8TM5AfZT5UIC7ge/iwHuyqxvAJ/qWYUCMGnFDwF5VK12Ar2e044CXE3NRgHmjg4NArlF2wgCJPFu/ZcLWq0g Content-Language: de-ch Subject: AW: [PHP-DEV] property de-referencing From: rstoll@tutteli.ch ("Robert Stoll") I have to agree with Etienne. Your idea is good, but it is probably = better to implement a better Refactoring support in the IDE rather than = enable it through the language itself. Dynamically typed languages will = always struggle with automatizing refactoring functionalities to a = certain extend. -----Urspr=C3=BCngliche Nachricht----- Von: ekneuss@gmail.com [mailto:ekneuss@gmail.com] Im Auftrag von Etienne = Kneuss Gesendet: Mittwoch, 1. Mai 2013 22:12 An: Rasmus Schultz Cc: Rasmus Lerdorf; Stas Malyshev; PHP internals Betreff: Re: [PHP-DEV] property de-referencing On Wed, May 1, 2013 at 7:13 PM, Rasmus Schultz = wrote: > The only reason being that the syntax "^$user->name" is "more static"=20 > 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=20 > are going to come from IDE support, but would include things like=20 > inline documentation, auto-complete and warnings/errors based on=20 > static analysis/inspections. I already covered that. > > PHP-based code-analysis tools would also be able to do a better job=20 > when checking views etc. - if you're using PHP-based static analysis=20 > tools to check for code-smells etc. there's a good chance you have it=20 > configured to skip your view-template folders... > > I am sorry, but I find very hard to believe that a "^" preceeding a = property access is going to make things easier for any static analysis, = and I have done my share of them. If you look even at the syntax tree, it is not any harder to track new = ReflectionProperty($obj, "property") than it is to track = ^$obj->property, and that is a fact. You basically have a string literal = instead of a T_STRING. You might argue that the property name does not need to be a string = literal, but then what about ^$foo->$bar or ^$foo->{'asd'}? would that = be forbidden? 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=20 > with a large codebase, and it's error-prone, and therefore requires=20 > manual review of every change before you apply, even for things that=20 > should be quick/simple like renaming a property. > Refactoring in PHP will always be guesswork, error-prone, and will = require manual inspection, whether you have a fancy syntax to create = ReflectionProperies or not. Types are hard to track statically and that = won't change with this. And really, the strict translation of ^$obj->foo = is just as easy (and fast) to track by analyses. > In any case, as many already pointed out, this sounds like a lot of=20 > 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=20 > demonstrated, valuable long-term gain from being able to write=20 > simpler, stronger abstractions that provide more comfort and safety in = an IDE. > I believe you have difficulties explaining these benefits because you = first need to argue why you want reflected properties all over the = place. And once that is established (assuming it is), why you would need = dedicated syntax for it. If reflected properties is a big thing, I'm sure "IDE support" is as = easy to implement with or without this new syntax. Introducing new syntax must be done with extreme care, and so far this = case looks quite far from convincing. > 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=20 >>> > 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=20 >>> 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 =3D ^$user->name; >>> >>> var_dump($nameprop->getValue()); // =3D> 'Rasmus' >>> >>> $nameprop->setValue('Bob'); >>> >>> var_dump($nameprop->getValue()); // =3D> 'Bob' >>> >>> The pre-processor output might look like this: >>> >>> $nameprop =3D new PropertyReference($user, 'name'); // $prop =3D=20 >>> ^$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=20 >> 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=20 >> pain for really little (if any) gain. >> >> >>> >>> var_dump($nameprop->getValue()); // =3D> 'Rasmus' >>> >>> $nameprop->setValue('Bob'); >>> >>> var_dump($nameprop->getValue()); // =3D> 'Bob' >>> >>> Only the first line changes - the rest behaves and runs like any=20 >>> normal PHP code. >>> >>> And the PropertyReference class could be implemented in plain PHP=20 >>> like >>> this: >>> >>> class PropertyReference >>> { >>> private $_object; >>> >>> private $_propertyName; >>> >>> public function __construct($object, $propertyName) >>> { >>> $this->_object =3D $object; >>> $this->_propertyName =3D $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} =3D $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/87c57301e0f6babb51026192b >>> d3db84ddaf84c83 >>> >>> 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/f2922b3a5dc0e12bf1e6fcacd >>> 8e73ff80717f3cb >>> >>> Note that the dynamic User::$name property in this example is=20 >>> 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=20 >>> > > implementation path, whatever. >>> > >>> > It doesn't. This is a fringe feature, as evidenced by the fact=20 >>> > that you are having a hard time convincing people that it is=20 >>> > needed, and thus shouldn't overload an existing operator. Visually = >>> > it would be confusing to take any well-known operator and give it=20 >>> > 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=20 >>> > carry this information with them so a lot of things would have to=20 >>> > change internally for this to ever work and if a clean=20 >>> > implementation could be found, like I said, adding it to the=20 >>> > reflection functions is the proper place. >>> > >>> > -Rasmus >>> > >>> >> >> >> >> -- >> Etienne Kneuss >> http://www.colder.ch >> > > -- Etienne Kneuss http://www.colder.ch