On Thu, May 2, 2013 at 2:07 AM, Rasmus Schultz <ras...@mindplay.dk> wrote:
> > 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.
>
> I thought that's what I had been doing? Apparently I've just been writing
> up long e-mails about nothing.
>
> I don't understand your line of argumentation at all - strings are fine
> and literal references to properties refactor just as well?
>
> Okay.
>
> Let's go ahead and quit using the new-statement then, because we don't
> really need literal references to class-names - we can just do this instead:
>
> function create($class_name)
> {
> return new $class_name;
> }
>
> $user = create('User');
>
> $user->name = 'xyz';
>
> See how far you'll get with static analysis when you don't even know the
> class of an object anymore. Solong to any kind of static analysis whatsover.
>
If this was an idiom in PHP, I'm sure static analyses would be built with
enough interprocedural reasoning to handle that case just fine.
>
> Let's get rid of the instanceof-operator while we're at it, this works
> just as well:
>
> if (get_class($user) === 'User') {
> // yay!
> }
>
> You are correct, we don't technically need literal references to anything.
>
> Forget the whole thing.
>
> I'm going to build every app in Drupal from now on, where everything is a
> string or an array or a stdClass - at least then there's consistently no
> checkable literals or IDE support for anything.
>
>
We have User::class now instead of 'User'. You should use it, it makes it
easy to refactor and stuff.
More seriously:
I'm just saying you are arguing for a *new* syntax that would allow
something rarely used (IMO) to be, as I see it: easier to analyze or
refactor; that doesn't qualify(IMO, again) as important enough to warrant a
syntax change.
> Awesome.
>
>
> On Wed, May 1, 2013 at 5:12 PM, Etienne Kneuss <col...@php.net> wrote:
>
>>
>>
>>
>> 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/87c57301e0f6babb51026192bd3db84ddaf84c83
>>>>>
>>>>> 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/f2922b3a5dc0e12bf1e6fcacd8e73ff80717f3cb
>>>>>
>>>>> 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
>>
>
>
>
--
Etienne Kneuss
http://www.colder.ch
