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 <smalys...@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
>
