Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67328 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50579 invoked from network); 7 May 2013 14:32:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 May 2013 14:32:24 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@mindplay.dk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@mindplay.dk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.181 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.220.181 mail-vc0-f181.google.com Received: from [209.85.220.181] ([209.85.220.181:48220] helo=mail-vc0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 51/D1-40623-77019815 for ; Tue, 07 May 2013 10:32:23 -0400 Received: by mail-vc0-f181.google.com with SMTP id hr11so544208vcb.40 for ; Tue, 07 May 2013 07:32:21 -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=fRf2SD15Fm22QizikHnAOWFUlwrwqTpYXwBpZbEnxGs=; b=EqqUOFsObJjXY3szxbeCPA+93N/rhME1EmgKONkNanfyCpaKgOWJOMgr+d/x8l5uZh sq6bTu0CuNUBHO4wgLcK1MQr2z213NwxVMQ+I+0I8a1xeJzXYCLXwZoyvFnp+bAFOba7 U++xl5ptKrRVHUYMrA7TaHjpvXdRAwlnoRBwsld7XNfihgBjFix1zgMF6bjz4m4/xVNH wO6rMh2xExNR9Drdwuu+RCvni1NApvjvMvuh7KfRfN3XY2PY2SWoajJMR0vEJxwwMgTK wcj1Vk+ZKHnfcO+OQc9N9l9M/2YFF1JTGxrC0IoSxFsKe0bH0szrGc0FJ0K47EPWPvra YHQg== MIME-Version: 1.0 X-Received: by 10.220.89.198 with SMTP id f6mr1402821vcm.45.1367937140836; Tue, 07 May 2013 07:32:20 -0700 (PDT) Received: by 10.58.28.134 with HTTP; Tue, 7 May 2013 07:32:20 -0700 (PDT) In-Reply-To: References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> Date: Tue, 7 May 2013 10:32:20 -0400 Message-ID: To: Seva Lapsha Cc: PHP internals Content-Type: multipart/alternative; boundary=047d7b343b425adff304dc21af3b X-Gm-Message-State: ALoCoQmQWkAL/6b+YRzC7yFYxF2uK0OWZZIdy+dGQeua0cswjBzPgJy0Kwm266sORL7HQvMBp6IH Subject: Re: [PHP-DEV] property de-referencing From: rasmus@mindplay.dk (Rasmus Schultz) --047d7b343b425adff304dc21af3b Content-Type: text/plain; charset=ISO-8859-1 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 >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> > --047d7b343b425adff304dc21af3b--