Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67323 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69613 invoked from network); 6 May 2013 18:46:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 May 2013 18:46:20 -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.128.170 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.128.170 mail-ve0-f170.google.com Received: from [209.85.128.170] ([209.85.128.170:38671] helo=mail-ve0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/56-22863-B7AF7815 for ; Mon, 06 May 2013 14:46:20 -0400 Received: by mail-ve0-f170.google.com with SMTP id 15so3595568vea.29 for ; Mon, 06 May 2013 11:46:17 -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=Pm495iTCpM0Qr71ZuZqbSnJqTvEgwdu2evsvRvVCf+I=; b=OO5qBW4diwWE8HKGModLHQlxbD0scK/qPLwodDv5qid4+8R5sZMpQLwfr2xINAxjo1 z6bfZnQw3RRiWDieXvtDR1Hs+ln17DJRZ22WPCaN4Lk8yqra90dq0CKPNuU2MdDMXTYK zv48Rcw36QQ2m6UPHncQrnwLnErO+bIXsLl0HFe/PetGSTIGhaQz2puQdyg00/75A0SS WkXTlz80IOFf1VAg8VdV9zIGTtaW2GNkEk0JYMNKkh+JIbP/hvdSr1nEmhUThc8XJh9V Fxu5ugwTDWSpMi7/Hp4ZvTRNeF/8/UVXg9lMQUuCljXp4FPdX8mvJH9dsTE2gn8uXM6g 7D7g== MIME-Version: 1.0 X-Received: by 10.220.68.13 with SMTP id t13mr5283870vci.24.1367865976835; Mon, 06 May 2013 11:46:16 -0700 (PDT) Received: by 10.58.28.134 with HTTP; Mon, 6 May 2013 11:46:16 -0700 (PDT) In-Reply-To: References: <6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net> <51803086.6020002@sugarcrm.com> Date: Mon, 6 May 2013 14:46:16 -0400 Message-ID: To: Seva Lapsha Cc: Stas Malyshev , PHP internals Content-Type: multipart/alternative; boundary=047d7b343d34a66a3304dc111d40 X-Gm-Message-State: ALoCoQkpXLMbTAII2fW7FWcJiCANG24acTvxI4AHdmFaruh4GNDqt7eGraqnTFAg14c2U8BCoBan Subject: Re: [PHP-DEV] property de-referencing From: rasmus@mindplay.dk (Rasmus Schultz) --047d7b343d34a66a3304dc111d40 Content-Type: text/plain; charset=ISO-8859-1 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 >>>> > >>>> >>> >>> >> > --047d7b343d34a66a3304dc111d40--