Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67330 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56864 invoked from network); 7 May 2013 15:24:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 May 2013 15:24:04 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@mindplay.dk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@mindplay.dk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.212.50 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.212.50 mail-vb0-f50.google.com Received: from [209.85.212.50] ([209.85.212.50:33918] helo=mail-vb0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 26/70-54258-29C19815 for ; Tue, 07 May 2013 11:24:02 -0400 Received: by mail-vb0-f50.google.com with SMTP id w16so589849vbb.9 for ; Tue, 07 May 2013 08:23:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=gzC5huhXGad16rsPFWyE8G46IMJwOesG2psP/yAZnPE=; b=f7eSBTeAXw4VlUfda3G4TO1TYDkYA6fzx5ce+LjQBQSLq1lEXhOT/GTHAvc8/m4QNJ JZGM1Ein9cHDQC+nPGsGK1YENnu2PO8vfRZ6Xq6FvTwc/qVpG1R8w1vV+RWE7IjSwlAp 8RFBMrqMA1Hdn/pb7Ybc8AI8UZGX7wVFdTxe+83QVjxtx4j4UtOxGLfMx+6FcvXOvzKY /SCkPDbFaj3lA1qfrSqDkpb+fJsPLgwKUelGoRBlTAF/g/zvtpPhWfqOKA4pquf/7Aee Ia7Kye/b/wrQC8/uiJ9BMY/d8lQKQFAqMpnJbweeGI+EIGojNq6/LJSwPskTgEzlmfhI nxqw== MIME-Version: 1.0 X-Received: by 10.221.9.9 with SMTP id ou9mr1576765vcb.15.1367940239681; Tue, 07 May 2013 08:23:59 -0700 (PDT) Received: by 10.58.28.134 with HTTP; Tue, 7 May 2013 08:23:59 -0700 (PDT) In-Reply-To: References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> Date: Tue, 7 May 2013 11:23:59 -0400 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary=089e0122947a0f81e204dc22684d X-Gm-Message-State: ALoCoQn0MAP6bY3h62jBwm7IfjiXZ6r0sGbBMIR9urh8GJvq1+VtF7j9ItyZpljbkIFbf4vZfZ2h Subject: Re: [PHP-DEV] property de-referencing From: rasmus@mindplay.dk (Rasmus Schultz) --089e0122947a0f81e204dc22684d Content-Type: text/plain; charset=ISO-8859-1 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 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 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 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 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 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 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 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 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: textInput(^$task->task) ?> >>>>>>>> Due Date: 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: input(^$task->task) ?> >>>>>>>> Due Date: 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 < >>>>>>>> smalyshev@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 >>>>>>>> > >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --089e0122947a0f81e204dc22684d--