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