Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67244
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.128.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <5180652D.1080007@lerdorf.com>
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>
Date: Wed, 1 May 2013 08:35:17 -0400
Message-ID: <CADqTB_jeWqSCz=3v4byBdJWrHnFV4kxPCkEWVRyYwz2XOSSEag@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01176751b330a904dba7598b
Subject: Re: [PHP-DEV] property de-referencing
From: rasmus@mindplay.dk (Rasmus Schultz)

--089e01176751b330a904dba7598b
Content-Type: text/plain; charset=ISO-8859-1

>
> 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 <rasmus@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
>

--089e01176751b330a904dba7598b--