Maybe PHP is just not for you. There are other languages in the sea :)
On Tue, May 7, 2013 at 10:32 AM, Rasmus Schultz <ras...@mindplay.dk> wrote:
> 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
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
