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üngliche Nachricht----- Von: ekne...@gmail.com [mailto:ekne...@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 <ras...@mindplay.dk> wrote: > 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... > > 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 > 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. > 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 > 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. > 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 <col...@php.net> wrote: > >> >> >> >> On Wed, May 1, 2013 at 2:35 PM, Rasmus Schultz <ras...@mindplay.dk>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/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 >>> properly documented and will reflect in an IDE. >>> >>> >>> On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf <ras...@lerdorf.com> >>> 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 >> > > -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
