Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67322
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_jqHCLKNMbCbpYrnJJJZNkW0YgZ1iJWqMf30qgPCZAHUg@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>
	<CAOtCo3rOOmYVTffgEDiMOAqDDit+=-+-Z5yx3-n=mVPdoExtSA@mail.gmail.com>
	<CADqTB_jqHCLKNMbCbpYrnJJJZNkW0YgZ1iJWqMf30qgPCZAHUg@mail.gmail.com>
Date: Mon, 6 May 2013 13:12:25 -0400
Message-ID: <CAOtCo3q=DtY3F2y=n=JX8KsCRAbbT8CZp1Ed1da3zSVv4CbQCw@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=001a11c29f7e02562504dc0fce13
Subject: Re: [PHP-DEV] property de-referencing
From: seva.lapsha@gmail.com (Seva Lapsha)

--001a11c29f7e02562504dc0fce13
Content-Type: text/plain; charset=ISO-8859-1

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 <rasmus@mindplay.dk> 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 <seva.lapsha@gmail.com>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 <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
>>> >
>>>
>>
>>
>

--001a11c29f7e02562504dc0fce13--