Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain leedsmet.ac.uk designates 207.126.144.123 as permitted sender)
To: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] property de-referencing
Thread-Index: AQHORPCcrQnjOMRAYUSMab7TKd9yDJjtzIsAgACJu4CAAEN8gIAAVG+AgAA4dgCAAAm2AIAAGBeAgAAZWwCAAAYEAIAAB0+AgADG5ICAABpDEA==
Date: Wed, 1 May 2013 13:20:32 +0000
Message-ID: <3158105795AAC1408619EC8BA03384A92252B0A8@EXC-MBX02.leedsmet.ac.uk>
References: <CADqTB_gkE-2mmnE8AKWCx3rcHf8DVsgxVPO00usErnaoKjAv7g@mail.gmail.com>
	<6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net>
	<CADqTB_iGghhwuKb7StpjY7xogNM76_47rxL3O7G+T0zOK2Lf3g@mail.gmail.com>
	<CALJZF3hQC09_b=yzOF5F6V1ifC5wG1H4RmkTDg02awm0cC-tWA@mail.gmail.com>
	<CADqTB_gxnPt-PzpaBiTmX5iW81VyssvtZW5Ugto2vOw1NsZGZg@mail.gmail.com>
	<CAH-PCH6oHkTweqYsY3UqeaP9Jdqkrmj1DBhxueUv5uU-U7YrPg@mail.gmail.com>
	<CADqTB_gTVm1TMcg5iaUZ-WTZChdpj7s+-vLaa7BK54FA71T-Sg@mail.gmail.com>
	<51803086.6020002@sugarcrm.com>
	<CADqTB_inCPzQyN=VoTgVkvYN2p0gTGH-nEp=pAuL71N2P6e19Q@mail.gmail.com>
	<51805A00.4050803@lerdorf.com>
	<CADqTB_gv82cq_4YyLgwvt5r+NZ4h_CjqKc=bbjt1MYE6eJu28g@mail.gmail.com>
	<5180652D.1080007@lerdorf.com>
 <CADqTB_jeWqSCz=3v4byBdJWrHnFV4kxPCkEWVRyYwz2XOSSEag@mail.gmail.com>
In-Reply-To: <CADqTB_jeWqSCz=3v4byBdJWrHnFV4kxPCkEWVRyYwz2XOSSEag@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] property de-referencing
From: M.Ford@leedsmet.ac.uk ("Ford, Mike")

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 t=
he 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 woul=
d want to add to:

   class User
   {
       public $name;
   }

   $user =3D new User;
   $user->name =3D 'Rasmus';

   $nameprop =3D &$user->name;

   var_dump($nameprop); // =3D> 'Rasmus'

   $nameprop =3D 'Bob';

   var_dump($nameprop); // =3D> 'Bob'


I would be immensely grateful, as I might then stand a chance of deciding w=
hether I'm with you or agin you...!


Cheers!

Mike

--=20
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,=20=20
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS,=A0 LS1 3HE,=A0 United Kingdom=20
E: m.ford@leedsmet.ac.uk     T: +44 113 812 4730


> -----Original Message-----
> From: Rasmus Schultz [mailto:rasmus@mindplay.dk]
> Sent: 01 May 2013 13:35
> To: Rasmus Lerdorf
> Cc: Stas Malyshev; PHP internals
> Subject: Re: [PHP-DEV] property de-referencing
>=20
> >
> > This is a fringe feature, as evidenced by the fact that you
> > are having a hard time convincing people that it is needed
>=20
>=20
> 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.
>=20
> Properties simply don't carry
> > this information with them so a lot of things would have to change
> > internally for this to ever work
>=20
>=20
> I'm not sure what information you're referring to?
>=20
> Let's say for the sake of argument, I'm going to use a pre-processor
> to
> transform the following code:
>=20
> $prop =3D ^$user->name;
>=20
> var_dump($nameprop->getValue()); // =3D> 'Rasmus'
>=20
> $nameprop->setValue('Bob');
>=20
> var_dump($nameprop->getValue()); // =3D> 'Bob'
>=20
> The pre-processor output might look like this:
>=20
> $nameprop =3D new PropertyReference($user, 'name'); // $prop =3D ^$user-
> >name;
>=20
> var_dump($nameprop->getValue()); // =3D> 'Rasmus'
>=20
> $nameprop->setValue('Bob');
>=20
> var_dump($nameprop->getValue()); // =3D> 'Bob'
>=20
> Only the first line changes - the rest behaves and runs like any
> normal PHP
> code.
>=20
> And the PropertyReference class could be implemented in plain PHP
> like this:
>=20
> class PropertyReference
> {
>     private $_object;
>=20
>     private $_propertyName;
>=20
>     public function __construct($object, $propertyName)
>     {
>         $this->_object =3D $object;
>         $this->_propertyName =3D $propertyName;
>     }
>=20
>     public function getObject()
>     {
>         return $this->_object;
>     }
>=20
>     public function getPropertyName()
>     {
>         return $this->_propertyName;
>     }
>=20
>     public function getValue()
>     {
>         return $this->_object->{$this->_propertyName};
>     }
>=20
>     public function setValue($value)
>     {
>         $this->_object->{$this->_propertyName} =3D $value;
>     }
>=20
>     // and maybe:
>=20
>     public function getReflection()
>     {
>         return new ReflectionObject($this->_object);
>     }
> }
>=20
>=20
> You can see the above example running in a sandbox here:
>=20
> http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192b
> d3db84ddaf84c83
>=20
> 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:
>=20
> http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd
> 8e73ff80717f3cb
>=20
> Note that the dynamic User::$name property in this example is
> properly
> documented and will reflect in an IDE.
>=20
>=20
> On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf <rasmus@lerdorf.com>
> wrote:
>=20
> > 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