And what do good developers do when the best ways have long since been
identified - and the limitations of the language prevents them from
implementing any new ideas?
I have hundreds of PHP experiments collected in a sandbox over the years -
a good way to build and handle web-forms is one of the last things I have
not found a satisfying solution to, and I am not happy with what anybody
else has come up with either. At some point, it's natural to start asking
why, comparing to other languages, etc. - short of inventing DSLs, I have
not seen much that really impresses me.
I don't know, maybe I should just let that one go and accept that it's
always going to be crap. Maybe the problem in the first place is trying to
drive the client-side from the server-side, and maybe client-side
frameworks is the right way to go - put the UI abstraction in the UI rather
than on the server. We'll always need a few web-forms, I think, but maybe
it's time to stop struggling for better server-side form handling and start
moving towards fully client-side UI...
(sorry if I'm going off on a tangent here - just sharing some of the
thoughts that lead me down this path to begin with...)
On Tue, May 7, 2013 at 9:41 AM, Seva Lapsha <seva.lap...@gmail.com> wrote:
> 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
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
