Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67228
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.128.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <51803086.6020002@sugarcrm.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>
Date: Tue, 30 Apr 2013 18:24:59 -0400
Message-ID: <CADqTB_inCPzQyN=VoTgVkvYN2p0gTGH-nEp=pAuL71N2P6e19Q@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf3071cde2c217d704db9b78df
Subject: Re: [PHP-DEV] property de-referencing
From: rasmus@mindplay.dk (Rasmus Schultz)

--20cf3071cde2c217d704db9b78df
Content-Type: text/plain; charset=ISO-8859-1

Any PHP dev who works with a mainstream framework does this daily, but the
frameworks rely on strings for property-names.

Take this example from the Symfony manual, for example:


        class Task
        {
            protected $task;

            protected $dueDate;

            public function getTask()
            {
                return $this->task;
            }
            public function setTask($task)
            {
                $this->task = $task;
            }

            public function getDueDate()
            {
                return $this->dueDate;
            }
            public function setDueDate(\DateTime $dueDate = null)
            {
                $this->dueDate = $dueDate;
            }
        }

        $form = $this->createFormBuilder($task)
            ->add('task', 'text')
            ->add('dueDate', 'date')
            ->getForm();

In this example, 'task' and 'dueDate' are property-references - except of
course that, no, they're not - they're obviously just strings... rewriting
this example to use a (fictive) form builder API with static
property-references:

        $form = $this->createFormBuilder()
            ->add(^$task->task, 'text')
            ->add(^$task->dueDate, 'date')
            ->getForm();

We now have static property-references, which means the codebase can be
proofed using static analysis, which also means better IDE support with
property auto-completion, inline documentation, and automatic refactoring
for operations like renaming properties, etc.

Note that $task need not be passed to createFormBuilder() anymore -
instead, we can now use PropertyReference::getObject() inside the
form-builder to obtain the instance.

For that matter, we can now scrap the form-builder entirely and introduce a
simple form-helper in the view instead:

    Task name: <?= $form->textInput(^$task->task) ?>
    Due Date: <?= $form->dateInput(^$task->dueDate) ?>

This is even better, because we now have the same level of IDE support and
static analysis for textInput() and dateInput() which were previously
unchecked strings.

Or even simpler:

    Task name: <?= $form->input(^$task->task) ?>
    Due Date: <?= $form->input(^$task->dueDate) ?>

Using PropertyReference::getObject() and reflection inside the
form-helper's input() method, we can now use property-annotations to
specify the input-type. This is a matter of preference of course, but use
of annotations in Symfony is pretty popular.

This is just one example - most PHP devs (at least those who do PHP for a
living) use form abstractions and object/relational-mappers of some sort,
so this has practical applications for practically everyone, everywhere.

Rasmus Lerdorf wrote:

It is certainly not worth overloading the XOR operator for


Are we really going to quibble about syntax? This adds nothing to this
discussion. And as I explained earlier, the ^ operator is used for the sake
of discussion only - if it's more practical to use another character for
this operator, I don't care what it looks like.


On Tue, Apr 30, 2013 at 4:58 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > I'm proposing we need a way to statically reference an object property -
> > the object property itself, not it's value:
>
> You probably have use case for that, and it should be pretty easy to
> write a class that does that, but why it should be in the language? It
> certainly doesn't look like something sizeable portion of PHP devs would
> do frequently.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

--20cf3071cde2c217d704db9b78df--