I know I'm still somewhat of a beginner with OOP, and not at all into large-scale OOP
frameworks (yet!), but I'm really struggling to understand why the existing & reference
operator doesn't suffice for what you are after?
If you could explain in words of as few syllables as possible what you would want to add to:
class User
{
public $name;
}
$user = new User;
$user->name = 'Rasmus';
$nameprop = &$user->name;
var_dump($nameprop); // => 'Rasmus'
$nameprop = 'Bob';
var_dump($nameprop); // => 'Bob'
I would be immensely grateful, as I might then stand a chance of deciding whether I'm with you
or agin you...!
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: [email protected] T: +44 113 812 4730
> -----Original Message-----
> From: Rasmus Schultz [mailto:[email protected]]
> Sent: 01 May 2013 13:35
> To: Rasmus Lerdorf
> Cc: Stas Malyshev; PHP internals
> Subject: Re: [PHP-DEV] property de-referencing
>
> >
> > 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/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 <[email protected]>
> 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
> >
To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm