> 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 am not sure if I understand you correctly. Do you mean you would not got far with static code analysis without the additional static information like @var etc.? If so, then I agree, would be much more difficult and less successful. But look at PHPStrom, I have at least the impression this IDE does already a lot without adding @var etc. However, static code analysis is the key for a better support within the IDE and the more static information is available for the IDE, the better the support. But that is not really the topic of the discussion, so I will stop here and only add that as I said and Etienne before, you could achieve your desire for better refactoring support for the construct new PropertyReference($user, 'name'); without the need of a new language feature. If the IDE knows what new PropertyReference($user, 'name'); stands for, then it is the same as ^$user->name; because it is only a shorthand. Or did I miss something of the new language feature?
> 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. > It does not in my opinion, but as you have come to know it is quite difficult to convince this mailing list about it. > PHP for any serious purpose has to be so heavily decorated, it's already being used dominantly as a static language. > I agree, most PHP users write PHP code in a much more static way than the language itself enables it (without frameworks etc.). > 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? > I think they actually do. PHP shall remain a weak and dynamically typed programming language and they probably fear that PHP could become more and more Java like (thats at least what I have read a few times here). But apart from that, the question they could ask themselves could also be, is it worth it to include your new language feature in PHP itself or should IDE developers bother with it. What is the influence on performance during runtime, additional complexity and maintenance of PHP core code etc.? Why not leave it to the IDE developers and performance loss is only occurring during development time. In my opinion this is the better choice, since PHP lacks a lot of static type enforcements, it is a dynamically typed language respectively. In addition your new feature is only syntactic sugar and can be achieved with more or less the same amount of code. Sorry, I have to ask again, did I miss something of your new language feature or is it really just a shorthand for new PropertyReference($user, 'name');? Von: Rasmus Schultz [mailto:ras...@mindplay.dk] Gesendet: Donnerstag, 2. Mai 2013 14:14 An: Robert Stoll Cc: Etienne Kneuss; Rasmus Lerdorf; Stas Malyshev; PHP internals Betreff: Re: [PHP-DEV] property de-referencing 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. thats 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 thats 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 thats perfectly reasonable. Btw thats 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 doesnt 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 doesnt 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
