> > As you described, IDEs struggle when it comes to Refactoring support for > PHP code and they always will without additional static information like > @var and @property annotations. And even with the static information in > addition, the IDEs still struggle and refactoring PHP code is quite painful > compared to other strictly typed programming languages, since it will > always need the manual approval from the user.
That's what I've been trying to say - some people seem to think we can just use strings for everything and static analysis will somehow walk execution paths and use intelligent algorithms (or dark sorcery) to determine which strings are what... That's not happening, not even in leading IDEs, not for any dynamic language, and I don't see how it could. IDEs are already struggling with real-time static analysis, even on fast computers, and with the amount of voluntary static information provided by developers. Let's strip all the static annotations from a large codebase like Symfony, Zend, WordPress, Drupal, etc. - and see how a developer who has never worked with one of those will fare? I'm betting you wouldn't get very far. Even if you could somehow analyze all possible execution paths in an entire codebase, I don't think you would get very far with static analysis. > I think most of the PHP developers (not users) do not want to change it > and want to keep the dynamic aspect of the language. How does adding more static features to a language that already has mixed typing interfere with the dynamic aspect of the language? I don't understand that mode of thinking. PHP for any serious purpose has to be so heavily decorated, it's already being used dominantly as a static language. Adding more static features does not have to influence the dynamic aspects, at all - use typing when you want it, and don't use it when you don't want it, same as any other language with mixed typing. There are other languages that pull that off successfully. I get the impression that most of the PHP developers do not want to change it, because the want the dynamic aspects of the language to remain dominant? Well, look at any modern PHP codebase out there - the source-code is dominantly statically typed, and has been for years. Dynamic features are reserved for the times when something dynamic really adds value and you can live with the trade-offs, but those cases are islands in an ocean of statically decorated code. that’s the reason why I came up with the project Type-Safe PHP Myself and others have come up with similar libraries over the years - so yes, the need is there, this is a symptom. Every codebase is full of static information - it's considered very bad practice by the community at large to not decorate your code with static information. That's a symptom. Why are static features seen as a threat to dynamic features? In languages with mixed typing, it's not a struggle between statics and dynamics - it's just a choice. They complement each other. They do not compete. It's not a contest. On Thu, May 2, 2013 at 8:02 AM, Robert Stoll <rst...@tutteli.ch> wrote: > Hi Rasmus**** > > ** ** > > I agree, a high level language should facilitate the development and it > should do as much as possible for the user. As you described, IDEs struggle > when it comes to Refactoring support for PHP code and they always will > without additional static information like @var and @property annotations. > And even with the static information in addition, the IDEs still struggle > and refactoring PHP code is quite painful compared to other strictly typed > programming languages, since it will always need the manual approval from > the user.**** > > ** ** > > In my opinion your idea is better than using strings (however, I do not > like the ^ but that’s a detail) and I would also like that the language > enforces static types etc. instead of using @var, @return etc. But I think > most of the PHP developers (not users) do not want to change it and want to > keep the dynamic aspect of the language. I think that’s perfectly > reasonable. Btw that’s the reason why I came up with the project Type-Safe > PHP (http://tsphp.tutteli.ch). **** > > ** ** > > I have the impression you will not go very far with your idea to introduce > a new language feature. But that doesn’t mean that your idea was worthless. > I think it is a next step to better refactoring support within IDEs and the > IDEs developer should consider to improve their data flow analysis and > extend their capabilities and support PropertyReference etc. If they can > handle PropertyReference then it doesn’t matter if you use your syntax:*** > * > > ** ** > > ^$user->name;**** > > ** ** > > or**** > > ** ** > > new PropertyReference($user, 'name');**** > > ** ** > > because it is the same in a static analysis point of view. Imagine an > abstract syntax tree. They would look alike because ^$user->name; is only a > shorthand for new PropertyReference($user, 'name');**** > > ** ** > > Cheers,**** > > Robert**** > > ** ** > > ** ** > > ** ** > > *Von:* Rasmus Schultz [mailto:ras...@mindplay.dk] > *Gesendet:* Donnerstag, 2. Mai 2013 01:51 > *An:* Robert Stoll > *Cc:* Etienne Kneuss; Rasmus Lerdorf; Stas Malyshev; PHP internals > > *Betreff:* Re: [PHP-DEV] property de-referencing**** > > ** ** > > 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**** > > ** ** >
