Good developers research and find *best* ways to use the available tools
before inventing new ones.
On Mon, May 6, 2013 at 2:46 PM, Rasmus Schultz <ras...@mindplay.dk> wrote:
> Well, I don't disagree as such - there's any number of (mostly bad) ways
> to work around missing language features...
>
>
> On Mon, May 6, 2013 at 1:12 PM, Seva Lapsha <seva.lap...@gmail.com> wrote:
>
>> BTW, I didn't propose to wrap any use of a property reference into a meta
>> object, in this case a certain distinguishable string format could
>> represent it with no extra handling.
>>
>>
>> On Mon, May 6, 2013 at 12:44 PM, Rasmus Schultz <ras...@mindplay.dk>wrote:
>>
>>> Seva,
>>>
>>> I understand that you can reference properties more consistently
>>> using "{fullClassName}::{fieldName}" notation, but it's still a string, and
>>> although it's now almost practically safe to assume that strings formatted
>>> in that way are property-references, it still doesn't address the problem
>>> in a way that is elegant or expressive.
>>>
>>> I don't think the Symfony component could have done a much better job
>>> under the circumstances, at least not without the sacrifice of readable
>>> code - typing out new PropertyReference($object, 'User::$name') sure would
>>> be clunky, and not even really safe, since you can't guarantee that the
>>> class-name of $object is known, and in every property-reference, the User
>>> class-reference is now embedded statically in every property-reference, in
>>> the form of a string.
>>>
>>> I think this is a good example of those times when PHP developers tend
>>> to look far, far away from Java - as far away as possible - for solutions
>>> that are elegant and a good fit for PHP.
>>>
>>> new PropertyReference($object, 'User::$name') contains two static
>>> references too many, to both PropertyReference and User.
>>>
>>> As opposed to ^$user->name which contains the minimum amount of required
>>> information - the object and property-name, nothing else.
>>>
>>>
>>> On Mon, May 6, 2013 at 12:08 PM, Seva Lapsha <seva.lap...@gmail.com>wrote:
>>>
>>>> Hi Rasmus,
>>>>
>>>> I agree with you that strings are not the best way to refer to an
>>>> element sometimes. However, to me your Symfony2 example only demonstrates
>>>> the flaw of the component's design decision, not the limitation of the
>>>> language. Sometimes developers (not just Symfony, but other frameworks too)
>>>> don't hesitate to use contextless strings to refer to meta-data, because
>>>> they underestimate the importance of keeping static referability of static
>>>> entities. If they would use conventional full notation of references, e.g.
>>>> "{fullClassName}::{fieldName}" in a string, this would solve your initial
>>>> problem (and allow static analyzers which could be aware of the context of
>>>> the framework to do their job). This is how these kind of dilemmas are
>>>> solved in the world of Java for instance, where property references don't
>>>> exist too.
>>>>
>>>> Regards,
>>>> Seva
>>>>
>>>>
>>>> On Tue, Apr 30, 2013 at 6:24 PM, Rasmus Schultz <ras...@mindplay.dk>wrote:
>>>>
>>>>> 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
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
