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