2013/5/1 Rasmus Schultz <ras...@mindplay.dk>
> 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();
>
One problem I have with this example is, that you usually (or at least
often) don't have a "$task" object here.
>
> 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
> >
>
--
github.com/KingCrunch
