Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67237 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77789 invoked from network); 1 May 2013 00:00:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 May 2013 00:00:59 -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.128.178 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.128.178 mail-ve0-f178.google.com Received: from [209.85.128.178] ([209.85.128.178:51198] helo=mail-ve0-f178.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E6/FE-18873-A3B50815 for ; Tue, 30 Apr 2013 20:00:58 -0400 Received: by mail-ve0-f178.google.com with SMTP id c13so896667vea.37 for ; Tue, 30 Apr 2013 17:00:56 -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:cc:content-type:x-gm-message-state; bh=pnemuT784y6/OWPNMuK1vapyStgaSH2n0z7TbPlEwPk=; b=lVi3rJQ2gviLRNvnYMO9N4By+SZUxDdrHaJH+sP/oKNZIFlr6n6d8P9fmUfv2QifMU RuuFNdUZAx1VdyoH/EE2v/6hmvryeqlKqrUsb780V3ei6tYmDmxB39+uDCP7tHv6e2EV 1o2QfI6ZNPpCKGX6g2it/pxKdzPRmbSPB+gKqcB3r3qYItI4iGl6FX8iUkY3oY+Dfj72 4X4a8jwcommo5XL+mIsCAOFmaHh0PIo0Xqws/YAer2azCIBo5Py/Mz/sj9Ms99LcjzqV F+6rlQ6Du7SGuIhv+cxi0mBk5l3QsCB2jxiCxkYc1giNh9fsJrbD03FlD8fB0ulpvo3d +YGQ== MIME-Version: 1.0 X-Received: by 10.52.18.173 with SMTP id x13mr138332vdd.121.1367366455908; Tue, 30 Apr 2013 17:00:55 -0700 (PDT) Received: by 10.58.28.134 with HTTP; Tue, 30 Apr 2013 17:00:55 -0700 (PDT) In-Reply-To: References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> Date: Tue, 30 Apr 2013 20:00:55 -0400 Message-ID: To: Sebastian Krebs Cc: Stas Malyshev , PHP internals Content-Type: multipart/alternative; boundary=bcaec50405c0e217ce04db9ccf6f X-Gm-Message-State: ALoCoQn1QazFu1yq0abJY4C9RvvWL3w6AbJi0z2/31fpYwfD8hr8iYFXTCgOTw0is+QXsMDCCV/b Subject: Re: [PHP-DEV] property de-referencing From: rasmus@mindplay.dk (Rasmus Schultz) --bcaec50405c0e217ce04db9ccf6f Content-Type: text/plain; charset=ISO-8859-1 > > one problem I have with this example is, that you usually (or at least > often) don't have a "$task" object here. I get what you're saying, but you do have a $task object if you want to use the form-builder, because it relies on the object for state. The same is true for most frameworks, and not generally a problem, since you can just create a transient (throw-away) object - this generally works fine, and has the added benefit of being able to initialize object properties with defaults. (such as today's date on a calendar entry form) On Tue, Apr 30, 2013 at 7:50 PM, Sebastian Krebs wrote: > > > > 2013/5/1 Rasmus Schultz > >> 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(); >> > > One problem I have with this example is, that you usually (or at least > often) don't have a "$task" object here. > > > >> >> 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 > >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 >> > >> > > > > -- > github.com/KingCrunch > --bcaec50405c0e217ce04db9ccf6f--