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 <ras...@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.lap...@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 <ras...@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 <smalys...@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 >>> > >>> >> >> >