>
> one problem I have with this example is, that you usually (or at least
> often) don't have a "$task" object here.
I get what you're saying, but you do have a $task object if you want to use
the form-builder, because it relies on the object for state.
The same is true for most frameworks, and not generally a problem, since
you can just create a transient (throw-away) object - this generally works
fine, and has the added benefit of being able to initialize object
properties with defaults. (such as today's date on a calendar entry form)
On Tue, Apr 30, 2013 at 7:50 PM, Sebastian Krebs <krebs....@gmail.com>wrote:
>
>
>
> 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
>
