>
> did I miss something of your new language feature or is it really
>
> just a shorthand for “new PropertyReference($user, 'name');”?
>
>
It is and it isn't.
Yes, that is effectively what it does, but that's not really the point.
The idea is to have a literal way to refer to an object property - in
syntax terms, 'name' is a string, but ^$user->name is a literal
property-reference.
Compare to the way you normally reference properties - in a sense,
properties are always referenced as strings in php. That is,
$user->{'name'} is functionally equivalent to $user->name. The difference
is in syntax - with $user->name it is implied that 'name' is a
property-name, whereas with $user->{'name'} the 'name' part is a string.
>From a purely functional perspective, $user->name isn't a necessary part of
PHP syntax at all - you could just as well use strings to reference *every*
property.
It wouldn't look very nice of course, but more importantly, the $user->name
syntax implies that 'name' is not just a string, but a property-reference.
Because it can be classified syntactically as a property-reference, it is
semantically different from a string, and provides (potentially) static
information.
A string passed as an argument to a method is always just a string - it
doesn't provide anymore static information than any other string that isn't
a property-reference. A string is a string. Literal references are
something else.
On Thu, May 2, 2013 at 5:31 PM, Robert Stoll <rst...@tutteli.ch> wrote:
>
> > 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 (that’s 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.
>
> 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
>
>
>
>
