Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67268 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14567 invoked from network); 2 May 2013 12:02:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 May 2013 12:02:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=rstoll@tutteli.ch; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rstoll@tutteli.ch; 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:44505] helo=hyperion.kreativmedia.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7E/05-06131-DB552815 for ; Thu, 02 May 2013 08:02:06 -0400 Received: (qmail 29812 invoked from network); 2 May 2013 14:02:02 +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; 2 May 2013 14:02:01 +0200 To: "'Rasmus Schultz'" Cc: "'Etienne Kneuss'" , "'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> <000f01ce46b4$52746360$f75d 2a20$@tutteli.ch> In-Reply-To: Date: Thu, 2 May 2013 13:02:01 +0100 Message-ID: <002b01ce472c$db882970$92987c50$@tutteli.ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CE4735.3D543290" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJH2Xu/ms45cks5g1geQvJz9rTAtQDV0/wKAYbXjrwB4fJnaQMQ8TM5AfZT5UIC7ge/iwHuyqxvAJ/qWYUCMGnFDwF5VK12Ar2e044CXE3NRgHmjg4NArlF2wgCJPFu/QJZUBdEAVoEWWeW7qmfYA== Content-Language: de-ch Subject: AW: [PHP-DEV] property de-referencing From: rstoll@tutteli.ch ("Robert Stoll") ------=_NextPart_000_002C_01CE4735.3D543290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rasmus =20 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. =20 In my opinion your idea is better than using strings (however, I do not = like the ^ but that=92s 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=92s perfectly reasonable. = Btw that=92s the reason why I came up with the project Type-Safe PHP (http://tsphp.tutteli.ch).=20 =20 I have the impression you will not go very far with your idea to = introduce a new language feature. But that doesn=92t 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=92t matter if you use your = syntax: =20 ^$user->name; =20 or =20 new PropertyReference($user, 'name'); =20 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'); =20 Cheers, Robert =20 =20 =20 Von: Rasmus Schultz [mailto:rasmus@mindplay.dk]=20 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 =20 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. =20 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. =20 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. =20 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. =20 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. =20 To write a simple web-application, I'm betting you would need a = QUADRILLION annotations to do that. =20 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. =20 Isn't that the reason languages evolved? =20 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? =20 Dynamically typed languages will always struggle with automatizing refactoring functionalities to a certain extend =20 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. =20 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. =20 Don't you think that's a symptom of something? =20 =20 On Wed, May 1, 2013 at 5:39 PM, Robert Stoll 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=FCngliche 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" > 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 = 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 >>> > 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 =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 >>> ^$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()); // =3D> 'Rasmus' >>> >>> $nameprop->setValue('Bob'); >>> >>> var_dump($nameprop->getValue()); // =3D> '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 =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 >>> 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 >>> > > 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 =20 ------=_NextPart_000_002C_01CE4735.3D543290--