Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67318
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_inCPzQyN=VoTgVkvYN2p0gTGH-nEp=pAuL71N2P6e19Q@mail.gmail.com>
References: <CADqTB_gkE-2mmnE8AKWCx3rcHf8DVsgxVPO00usErnaoKjAv7g@mail.gmail.com>
	<6245ED6B-2BF7-47B7-80C0-D3B3D8E0B312@strojny.net>
	<CADqTB_iGghhwuKb7StpjY7xogNM76_47rxL3O7G+T0zOK2Lf3g@mail.gmail.com>
	<CALJZF3hQC09_b=yzOF5F6V1ifC5wG1H4RmkTDg02awm0cC-tWA@mail.gmail.com>
	<CADqTB_gxnPt-PzpaBiTmX5iW81VyssvtZW5Ugto2vOw1NsZGZg@mail.gmail.com>
	<CAH-PCH6oHkTweqYsY3UqeaP9Jdqkrmj1DBhxueUv5uU-U7YrPg@mail.gmail.com>
	<CADqTB_gTVm1TMcg5iaUZ-WTZChdpj7s+-vLaa7BK54FA71T-Sg@mail.gmail.com>
	<51803086.6020002@sugarcrm.com>
	<CADqTB_inCPzQyN=VoTgVkvYN2p0gTGH-nEp=pAuL71N2P6e19Q@mail.gmail.com>
Date: Mon, 6 May 2013 12:08:49 -0400
Message-ID: <CAOtCo3rOOmYVTffgEDiMOAqDDit+=-+-Z5yx3-n=mVPdoExtSA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6243088bd31e04dc0eea56
Subject: Re: [PHP-DEV] property de-referencing
From: seva.lapsha@gmail.com (Seva Lapsha)

--047d7b6243088bd31e04dc0eea56
Content-Type: text/plain; charset=ISO-8859-1

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 <rasmus@mindplay.dk> 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: <?= $form->textInput(^$task->task) ?>
>     Due Date: <?= $form->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: <?= $form->input(^$task->task) ?>
>     Due Date: <?= $form->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
> >
>

--047d7b6243088bd31e04dc0eea56--