PhpStorm has the finest refactoring support you can achieve with the limited amount of static information in PHP source-code, plus hopefully a whole bunch of @var and @property annotations. With the amount of information inherent in PHP source-code, plus the volunteer information provided by annotations, it still has to do a lot of guess-work, and you still have to look over the proposed changes and manually correct what it gets wrong.
I really see annotations in doc-blocks as a symptom of the lack of static information in the language - the interpreter doesn't need information like property-types or argument-types, but as it turns out, people do, so we have to decorate the language with annotations to provide enough information for people to comprehend the code. But that means the annotations can now be out of sync with reality - argument-types and property-types change. We discover, there was a useful need for this information after all: type checking. So we introduce static type-hints. The static information wasn't just useful to humans after all. As for property-types and loads of other things, we annotate everything, in part because the annotations are useful to people, in part to facilitate proper IDE support and other forms of machine-analysis. Property type-hints may not be necessary to run the language, but they are necessary for people and external static analysis. PHP is not a machine-friendly language - like most high-level languages, it was designed with people in mind, which is natural, because people are the ones who use programming languages. The machines would be satisfied with machine instructions, if you could memorize them all and keep track of that in your head. To write a simple web-application, I'm betting you would need a QUADRILLION annotations to do that. Better to take all that static information and make it available to the machine, so that we can not only have languages people can read, write and understand - but exploit that rich static information to check that your code actually does what you say it does. Isn't that the reason languages evolved? Why are we always so concerned about what the language is doing, and so careless with expressiveness and information that makes it meaningful to human beings? Dynamically typed languages will always struggle with automatizing > refactoring functionalities to a certain extend PHP *was* a dynamically typed language - it is currently a mixed type language. You have optional static references to types in argument-lists - even if those are only checked dynamically by the interpreter, they are usually checked statically by every external tool. Every well-written application, library, framework etc *treats* PHP as a mixed-typed language most of the time, decorating the language up, down and center with static type-information, everywhere, all the time. Don't you think that's a symptom of something? On Wed, May 1, 2013 at 5:39 PM, Robert Stoll <rst...@tutteli.ch> wrote: > 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 > >
