Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67327 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46989 invoked from network); 7 May 2013 13:41:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 May 2013 13:41:51 -0000 Authentication-Results: pb1.pair.com header.from=seva.lapsha@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=seva.lapsha@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.177 as permitted sender) X-PHP-List-Original-Sender: seva.lapsha@gmail.com X-Host-Fingerprint: 209.85.215.177 mail-ea0-f177.google.com Received: from [209.85.215.177] ([209.85.215.177:36915] helo=mail-ea0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/31-40623-E9409815 for ; Tue, 07 May 2013 09:41:51 -0400 Received: by mail-ea0-f177.google.com with SMTP id o10so311980eaj.36 for ; Tue, 07 May 2013 06:41: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=6tOG07xkiqYAbgT97XWGWCyvn1F2V8klLY4NiguRllE=; b=G1v5ex1H8GIKiIBbYB7c1oG5VGdkpIfshagKDjuu+Cce4+u4AMIuXQG8DRrSWobkr9 57nvGoEsxFuSkkcMoUKibIivhSf+NQL6N7vidEQQTMnGyy1ROcpeC06fb/vlUU/UlGnI Vo+VUluE+Zf98hhdclPuk24wsLdvg/4cr3vFS4LW9fO4kOFKUFkymznEsj/NfLpUCc4+ tf4QzZ2t53f9uZoRmRpEdU00LqjXSvv8X4EYk8Jr83La73s0b8hOjOYGcIbXkneZGOta hoonbDy9On+pJK5oZfoghExVgeWlzNu6F7WAAw5lgF9CCJ4haR8dTDC8I3RpiRn5X60W N8vA== MIME-Version: 1.0 X-Received: by 10.14.102.9 with SMTP id c9mr5498551eeg.29.1367934107786; Tue, 07 May 2013 06:41:47 -0700 (PDT) Received: by 10.14.143.13 with HTTP; Tue, 7 May 2013 06:41:47 -0700 (PDT) In-Reply-To: References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> Date: Tue, 7 May 2013 09:41:47 -0400 Message-ID: To: Rasmus Schultz Cc: Stas Malyshev , PHP internals Content-Type: multipart/alternative; boundary=001a11c1b8d4924ccf04dc20faa2 Subject: Re: [PHP-DEV] property de-referencing From: seva.lapsha@gmail.com (Seva Lapsha) --001a11c1b8d4924ccf04dc20faa2 Content-Type: text/plain; charset=ISO-8859-1 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 >>>> >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 >>>>> > >>>>> >>>> >>>> >>> >> > --001a11c1b8d4924ccf04dc20faa2--