I have tried tons of other languages, actively watching at least a few
others in the hopes they'll mature - but I keep coming back to PHP for some
reason.
It's an abusive relationship. Maybe I should seek counseling ;-)
On Tue, May 7, 2013 at 11:15 AM, Seva Lapsha <seva.lap...@gmail.com> wrote:
> 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
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
