> 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.
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.
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
>
