Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67329 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55027 invoked from network); 7 May 2013 15:15:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 May 2013 15:15:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=seva.lapsha@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=seva.lapsha@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender) X-PHP-List-Original-Sender: seva.lapsha@gmail.com X-Host-Fingerprint: 209.85.215.170 mail-ea0-f170.google.com Received: from [209.85.215.170] ([209.85.215.170:53860] helo=mail-ea0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DE/00-54258-5AA19815 for ; Tue, 07 May 2013 11:15:50 -0400 Received: by mail-ea0-f170.google.com with SMTP id z7so374157eaf.1 for ; Tue, 07 May 2013 08:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=r13MAHFJJU6+L4qY+FkZ4/Qn2M3RqXPuRanmK2nFweg=; b=yFNtJu4P9CyMwc3q9Lr7lAtuvHTxPbK66dVSuLKaqep4Q0h51RlBgjkf9sPddBZZgA Nh/2deAz28zI2HlVuH674pH4a6DWKex46Qcse+sLe1JdIJ52YSUYPFzqiDrRXw4r/Zqc vf2tQ98LG0FqEx+YOZLyLHPBDcvOoHu9+I31XTPqFRGFVpbCDGAnqwCw5Z0cFv3BoHkE qvHsko9IXrnpnfzFiBAnBjzUzuPp3t/7WKYO+rVsNXPsYM839U2FzH9Bz8Nx1qAXsgDH z4Fhl1X+kvFK9UdOdW41tLWnyn5ezQtgCxbupHbFgnmbviO+rRaAk1QFRdQsisaM7RQC w0bQ== MIME-Version: 1.0 X-Received: by 10.14.109.131 with SMTP id s3mr6286037eeg.26.1367939740827; Tue, 07 May 2013 08:15:40 -0700 (PDT) Received: by 10.14.143.13 with HTTP; Tue, 7 May 2013 08:15:40 -0700 (PDT) In-Reply-To: References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> Date: Tue, 7 May 2013 11:15:40 -0400 Message-ID: To: Rasmus Schultz Cc: PHP internals Content-Type: multipart/alternative; boundary=001a11c29f7e53a85504dc224a29 Subject: Re: [PHP-DEV] property de-referencing From: seva.lapsha@gmail.com (Seva Lapsha) --001a11c29f7e53a85504dc224a29 Content-Type: text/plain; charset=ISO-8859-1 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 >>>>>>> > >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a11c29f7e53a85504dc224a29--