# property de-referencing

- Thread: https://externals.io/message/67147
- Original archive: https://news-web.php.net/php.internals/67147
- Started by Rasmus Schultz on 2013-04-25T12:47:21+00:00
- Messages: 61
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/67147.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #67147 — Rasmus Schultz — 2013-04-25T12:47:21+00:00

URL: https://externals.io/message/67147#67147

Okay,

No one seemed extremely interested in my notes about static
type-references<http://marc.info/?t=136327849600002&r=1&w=2>- I want
to bring up something closely related that could possibly be even
more useful, in particular for things like form-helpers, which remains as
one of the things that just can't be done in PHP as elegantly as it can in
some other languages.

I'm not sure if de-referencing is the correct term? I'm talking about the
ability to use a property-reference indirectly - meaning, don't read the
property, don't write the property, but reference the property in a way
that permits you to read/write the property later on.

In this example, I'm using ^ as the de-reference operator:

class User
{
    public $email;
}

$user = new User();

$form = new FormHelper($user);

echo $form->textInput(^$user->email);

Note the ^ operator in the last line - we're not passing the value of
$user->email to FormHelper::textInput() but a reference to it... assuming a
new internal PropertyReference class, it's declaration might look like this:

class FormHelper
{
    public function textInput(PropertyReference $prop)
    {
        $name = $prop->className . '[' . $prop->propertyName . ']';
        $value = $prop->getValue();

        return "<input type='text' name='{$name}' value='{$value}' />";
    }

    ....
}


The new PropertyReference class might have an interface like the following:

class PropertyReference
{
    public readonly object $object; // the object that was referenced
    public readonly string $className; // the type of object that was
referenced
    public readonly string $propertyName; // the name of the property that
was referenced

    public function getValue(); // read and return the property-value
    public function setValue($value); // write the property-value
}


For a statement like this:

$prop = ^$user->email;

The ^ operator does something equivalent to:

$prop = new PropertyReference();

$prop->object = $user;
$prop->className = get_class($user);
$prop->propertyName = 'email';

$prop->getValue = function () use ($user) {
    return $user->email;
};

$prop->setValue = function ($value) use ($user) {
    $user->email = $value;
};


So essentially, you get all the information about the object and property,
and a way to read/write that property, with one character - something that
would enable hugely convenient APIs for things like form-helpers,
data-mappers and object/relational-mappers.

When the object-type is known in IDEs (as it is in properly documented
code) this also addresses the same issue as static type-references,
allowing for static analysis and automated refactoring, but with a much
shorter and more convenient syntax - not needing to explicitly reference
the class-name, and with the added benefit of knowing the instance, both of
which are hugely important for form-helpers and mappers.

Note that the getValue() and setValue() closures resolve properties the
usual way - that is, you can de-reference magic properties too, since no
attempt is made to read or write the property until getValue() or
setValue() is made.

Most use-cases for referencing class and property-names are situations like
these, so this kind of kills two birds with one stone - a static way to
reference properties, but with the addition of providing the actual
object-context. And the shortest possible syntax.

What do you think?

- Rasmus Schultz

---

## #67149 — Nikita Popov — 2013-04-25T13:22:19+00:00

URL: https://externals.io/message/67147#67149 · In reply to: #67147

> Okay,
>
> No one seemed extremely interested in my notes about static
> type-references<http://marc.info/?t=136327849600002&r=1&w=2>- I want
> to bring up something closely related that could possibly be even
> more useful, in particular for things like form-helpers, which remains as
> one of the things that just can't be done in PHP as elegantly as it can in
> some other languages.
>
> I'm not sure if de-referencing is the correct term? I'm talking about the
> ability to use a property-reference indirectly - meaning, don't read the
> property, don't write the property, but reference the property in a way
> that permits you to read/write the property later on.
>
> In this example, I'm using ^ as the de-reference operator:
>
> class User
> {
>     public $email;
> }
>
> $user = new User();
>
> $form = new FormHelper($user);
>
> echo $form->textInput(^$user->email);
>
> Note the ^ operator in the last line - we're not passing the value of
> $user->email to FormHelper::textInput() but a reference to it... assuming a
> new internal PropertyReference class, it's declaration might look like
> this:
>
> class FormHelper
> {
>     public function textInput(PropertyReference $prop)
>     {
>         $name = $prop->className . '[' . $prop->propertyName . ']';
>         $value = $prop->getValue();
>
>         return "<input type='text' name='{$name}' value='{$value}' />";
>     }
>
>     ....
> }
>
>
> The new PropertyReference class might have an interface like the following:
>
> class PropertyReference
> {
>     public readonly object $object; // the object that was referenced
>     public readonly string $className; // the type of object that was
> referenced
>     public readonly string $propertyName; // the name of the property that
> was referenced
>
>     public function getValue(); // read and return the property-value
>     public function setValue($value); // write the property-value
> }
>
>
> For a statement like this:
>
> $prop = ^$user->email;
>
> The ^ operator does something equivalent to:
>
> $prop = new PropertyReference();
>
> $prop->object = $user;
> $prop->className = get_class($user);
> $prop->propertyName = 'email';
>
> $prop->getValue = function () use ($user) {
>     return $user->email;
> };
>
> $prop->setValue = function ($value) use ($user) {
>     $user->email = $value;
> };
>
>
> So essentially, you get all the information about the object and property,
> and a way to read/write that property, with one character - something that
> would enable hugely convenient APIs for things like form-helpers,
> data-mappers and object/relational-mappers.
>
> When the object-type is known in IDEs (as it is in properly documented
> code) this also addresses the same issue as static type-references,
> allowing for static analysis and automated refactoring, but with a much
> shorter and more convenient syntax - not needing to explicitly reference
> the class-name, and with the added benefit of knowing the instance, both of
> which are hugely important for form-helpers and mappers.
>
> Note that the getValue() and setValue() closures resolve properties the
> usual way - that is, you can de-reference magic properties too, since no
> attempt is made to read or write the property until getValue() or
> setValue() is made.
>
> Most use-cases for referencing class and property-names are situations like
> these, so this kind of kills two birds with one stone - a static way to
> reference properties, but with the addition of providing the actual
> object-context. And the shortest possible syntax.
>
> What do you think?
>
> - Rasmus Schultz
>

Maybe I didn't understand what you mean, but if you want property
references, why not just use, well, property references?

function foo(&$ref) { $ref = 'a'; }

$a = new Obj;
foo($a->prop);
var_dump($a->prop) // string(1) "a"

Also works for magic properties, assuming your correctly declared them
using &__get.

If you want more than just get/set, but also info on the property, why not
pass a ReflectionProperty or a modification thereof which has a pre-bound
object? Why do you need a new operator for this?

Nikita

---

## #67152 — Rasmus Schultz — 2013-04-25T15:02:36+00:00

URL: https://externals.io/message/67147#67152 · In reply to: #67149

>
> Maybe I didn't understand what you mean, but if you want property
> references, why not just use, well, property references?


Property-references don't know what property they're referencing - they
reference the object/value held by the property, not the property itself.

If you want more than just get/set, but also info on the property, why not
> pass a ReflectionProperty or a modification thereof which has a pre-bound
> object? Why do you need a new operator for this


That's what we have to do currently - that's why form-helpers and ORMs
currently rely on strings for property-references...

echo $form->textInput($user, 'email');


This example is fairly straight forward, and PHP developers are probably
used to reading code like this by now - but the meaning becomes
increasingly obscured the further you take things out of context:

$form = new FormHelper($user);

echo $form->textInput('email');


Now you have to think a little more to understand what's going on - the API
is more convenient now, but more obscured. It's also less flexible, since
now you have to manually switch objects or create more form-helpers to
handle more than one object.

echo $form->textInput($property_name);


Even more obscured, since now your local variable is definitely a string,
and you can no longer see which property we're talking about.

The root of this problem is the fact that 'email' is a string - the fact
that it references a source-code element is something that is merely
implied but can't be proven, which means you can't have proper IDE support
or static analysis. (by other means than sheer guesswork.)

As opposed to:

echo $form->textInput(^$user->email);


There is no question that you're referring to an object property here -
it's not a string and it's also an atomic reference to a particular object
and property combined, as opposed to the string and object as a detached
reference and value pair. Even if you have to pass these around:

class FormHelper
{
    public function textInput(PropertyReference $prop)
    {
        return $this->renderInput('text', $prop);
    }

    protected function renderInput($type, PropertyReference $prop)
    {
        ....
    }
}


You're no longer passing around a string detached from it's object context,
having to keep the object-reference as state or pass it around as a
separate argument from the property-name - the idea is to have formal
language-level support for a reference to an object property.

Yes, you can do that with strings and the Reflection API now - the point is
not whether or not it can already be done, the point is to make it part of
the language, so that you can use it based on more than just ideas and
assumptions, and so we can build libraries and applications with proper IDE
support.

Current codebases rely heavily on conventions and APIs - many popular
meta-programming techniques could be simplified and made more elegant,
easier to understand without having to learn conventions, faster to use,
and with support for static analysis.

- Rasmus Schultz




> On Thu, Apr 25, 2013 at 2:47 PM, Rasmus Schultz <rasmus@mindplay.dk>wrote:
>
> > […]
>
> Maybe I didn't understand what you mean, but if you want property
> references, why not just use, well, property references?
>
> function foo(&$ref) { $ref = 'a'; }
>
> $a = new Obj;
> foo($a->prop);
> var_dump($a->prop) // string(1) "a"
>
> Also works for magic properties, assuming your correctly declared them
> using &__get.
>
> If you want more than just get/set, but also info on the property, why not
> pass a ReflectionProperty or a modification thereof which has a pre-bound
> object? Why do you need a new operator for this?
>
> Nikita

---

## #67194 — Lars Strojny — 2013-04-29T09:22:12+00:00

URL: https://externals.io/message/67147#67194 · In reply to: #67147

Hi Rasmus,

Am 25.04.2013 um 14:47 schrieb Rasmus Schultz <rasmus@mindplay.dk>:
[...]
> 
> What do you think?


I'm not sure about the operator character but the general idea is a good one. Do you have a patch as a POC?

cu,
Lars

---

## #67204 — Rasmus Schultz — 2013-04-29T23:45:14+00:00

URL: https://externals.io/message/67147#67204 · In reply to: #67194

The characters was an arbitrary choice, just for the sake of argument.

I'm not a C programmer, so I don't have a patch - there is also no RFC, but
there is general interest, I'd be happy to write one.



> Hi Rasmus,
>
> Am 25.04.2013 um 14:47 schrieb Rasmus Schultz <rasmus@mindplay.dk>:
> [...]
> > […]
>
>
> I'm not sure about the operator character but the general idea is a good
> one. Do you have a patch as a POC?
>
> cu,
> Lars

---

## #67207 — Michael Wallner — 2013-04-30T07:58:11+00:00

URL: https://externals.io/message/67147#67207 · In reply to: #67204

> The characters was an arbitrary choice, just for the sake of argument.
>
> I'm not a C programmer, so I don't have a patch - there is also no RFC, but
> there is general interest, I'd be happy to write one.
>
> 
>
> > […]
>

Do you mean something yucky like http://pecl.php.net/propro?
It's actually been meant to be used by extensions for internal properties,
but it might do the evil you're looking for.


-- 
Regards,
Mike

---

## #67213 — Rasmus Schultz — 2013-04-30T11:59:43+00:00

URL: https://externals.io/message/67147#67213 · In reply to: #67207

>
> Do you mean something yucky like http://pecl.php.net/propro?
>
>
I don't know what that is, and there is no description on that page.


> It's actually been meant to be used by extensions for internal properties,
> > […]
>
>
Would you care to elaborate? What is evil about the thing I've described?




> 
>
> > […]
>
> Do you mean something yucky like http://pecl.php.net/propro?
> It's actually been meant to be used by extensions for internal properties,
> but it might do the evil you're looking for.
>
>
> --
> Regards,
> Mike

---

## #67217 — Ferenc Kovacs — 2013-04-30T17:01:55+00:00

URL: https://externals.io/message/67147#67217 · In reply to: #67213

2013.04.30. 14:00, "Rasmus Schultz" <rasmus@mindplay.dk> ezt írta:
>
> > […]
> I don't know what that is, and there is no description on that page.

you can grasp the concept from the testcase:
http://git.php.net/?p=pecl/php/propro.git;a=blob_plain;f=tests/001.phpt;hb=HEAD

---

## #67222 — Rasmus Schultz — 2013-04-30T20:24:00+00:00

URL: https://externals.io/message/67147#67222 · In reply to: #67217

That looks more pointless than evil to me - and no, I'm not suggesting
anything of that sort.

I'm proposing we need a way to statically reference an object property -
the object property itself, not it's value:

    var_dump($user->name); // => 'Rasmus'

    var_dump(^$user->name); // => PropertyReference(class: 'User',
propertyName: 'name', object:User(...))

    $foo = ^$user->name;

    var_dump($foo->getValue()); // => 'Rasmus'

    $foo->setValue('Bob');

    var_dump($user->name); // => 'Bob'

Is that easier to understand?

- Rasmus Schultz




>
> 2013.04.30. 14:00, "Rasmus Schultz" <rasmus@mindplay.dk> ezt írta:
>
> > […]
>
> you can grasp the concept from the testcase:
>
> http://git.php.net/?p=pecl/php/propro.git;a=blob_plain;f=tests/001.phpt;hb=HEAD

---

## #67223 — ALeX — 2013-04-30T20:36:14+00:00

URL: https://externals.io/message/67147#67223 · In reply to: #67222

Just an idea: why not also use ^ (or another operator) to access the
value? (maybe as an additional way to get/setValue)

$foo = ^$user->name;

echo 'Hello '.^$foo;
^$foo = 'Bob';

(using the same operator will conflict when you are accessing a
property of an object which is a PropertyReference)

---

## #67224 — Rasmus Schultz — 2013-04-30T20:58:21+00:00

URL: https://externals.io/message/67147#67224 · In reply to: #67223

I don't think that's necessary - the point of being able to do this, is to
apply meta-programming techniques, so in most situations, what matters is
the ability to quickly create object/property-references... using them will
usually happen inside some service component, e.g. a form-helper or
object/relational-mapper. Having a short syntax for that is much less
relevant - what matters if easy (and of course static) creation of
references to those objects/properties.



> Just an idea: why not also use ^ (or another operator) to access the
> value? (maybe as an additional way to get/setValue)
>
> $foo = ^$user->name;
>
> echo 'Hello '.^$foo;
> ^$foo = 'Bob';
>
> (using the same operator will conflict when you are accessing a
> property of an object which is a PropertyReference)

---

## #67225 — Stas Malyshev — 2013-04-30T20:58:46+00:00

URL: https://externals.io/message/67147#67225 · In reply to: #67222

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

---

## #67226 — Rasmus Lerdorf — 2013-04-30T21:00:45+00:00

URL: https://externals.io/message/67147#67226 · In reply to: #67225

> Hi!
> 
> > […]
> 
> 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.

It is certainly not worth overloading the XOR operator for.

-Rasmus

---

## #67227 — Lazare Inepologlou — 2013-04-30T22:20:07+00:00

URL: https://externals.io/message/67147#67227 · In reply to: #67226

2013/4/30 Rasmus Lerdorf <rasmus@lerdorf.com>

> 
> > […]
>
> It is certainly not worth overloading the XOR operator for.
>
> -Rasmus
>
>
In C#, they had the intention to introduce the operator infoof(...) to get
the reflection, not only of properties, but of virtually everything in the
language. They abandoned the idea because it is really hard to do that for
overloaded functions and they did not want to do all that work for a half
baked feature:

http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx

However, PHP does not have overloaded functions, which makes things
significantly easier, so maybe it is worth examining the idea.


Lazare INEPOLOGLOU
Ingénieur Logiciel

---

## #67228 — Rasmus Schultz — 2013-04-30T22:24:59+00:00

URL: https://externals.io/message/67147#67228 · In reply to: #67225

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!
>
> > […]
>
> 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

---

## #67229 — Stas Malyshev — 2013-04-30T23:12:15+00:00

URL: https://externals.io/message/67147#67229 · In reply to: #67227

Hi!

> In C#, they had the intention to introduce the operator infoof(...) to
> get the reflection, not only of properties, but of virtually everything
> in the language. They abandoned the idea because it is really hard to do
> that for overloaded functions and they did not want to do all that work
> for a half baked feature:
> 
> http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx
> 
> However, PHP does not have overloaded functions, which makes things
> significantly easier, so maybe it is worth examining the idea.

PHP has functions that can be result of __call or arbitrary code that
implements fcall handler in an extension. What would be returned then?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #67230 — Rasmus Schultz — 2013-04-30T23:15:48+00:00

URL: https://externals.io/message/67147#67230 · In reply to: #67227

I suggested something similar earlier:

http://marc.info/?t=136327849600002&r=1&w=2

However, I withdrew that idea, because I came to the realization that, for
practical applications, you usually need the object-context coupled with
the member-reference to do anything really useful.

A form-input abstraction, for example, needs the object-context to reflect
on the class, the property-reference to reflect on annotations (maybe) and
of course the property-value, plus the ability to apply a posted value back
onto to the object-property.

The proposed feature facilitates all of that.

At the risk of starting a separate discussion, the recently added
ClassName::class constant provides a way to statically reference a class,
which frankly has very few practical applications in comparison - the need
to reference properties is usually much more prevalent and repetitive than
the need to reference a class; assuming your classes have more than one
property each, heh. The feature as such is also somewhat crippled, since
what comes out of it is a string and not a class-reference.

It solves the problems of static class-references of course, so that's
positive - but where's the much more critical property-reference
counterpart? Because this feature overloads class-constant syntax, there is
no obvious counterpart for properties. It seems pretty short-sighted. If
referencing a class statically is necessary and important enough to make it
into the language, why are property-references considered less important or
valuable?

Try to think of these features in terms of completing or complementing the
fairly limited static side of an otherwise mostly dynamic language, rather
than as features intended to solve a specific programming problem as such.

I think there is still a pretty strong case for static property-references,
but since any new language-feature is generally a pretty hard sell around
here, I'm letting this one go for now.

The immediate impact and benefits of static object-property references
ought to be a much easier sell - it has pretty broad applications, and can
probably replace a lot of simple inline function-closures, and eliminate a
lot of double-arguments (object and property-name) from many
popular/mainstream libraries.

If you disagree, please explain by example. I've already put a lot of time
into thinking about this and explaining it pretty carefully. If you're
opposed for more than personal reasons, surely you can offer more than a
flippant one-line backlash? :-)


On Tue, Apr 30, 2013 at 6:20 PM, Lazare Inepologlou <linepogl@gmail.com>wrote:

>
>
> 2013/4/30 Rasmus Lerdorf <rasmus@lerdorf.com>
>
> > […]
> In C#, they had the intention to introduce the operator infoof(...) to get
> the reflection, not only of properties, but of virtually everything in the
> language. They abandoned the idea because it is really hard to do that for
> overloaded functions and they did not want to do all that work for a half
> baked feature:
>
>
> http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx
>
> However, PHP does not have overloaded functions, which makes things
> significantly easier, so maybe it is worth examining the idea.
>
>
> Lazare INEPOLOGLOU
> Ingénieur Logiciel

---

## #67231 — Stas Malyshev — 2013-04-30T23:16:52+00:00

URL: https://externals.io/message/67147#67231 · In reply to: #67228

Hi!

> Any PHP dev who works with a mainstream framework does this daily, but
> the frameworks rely on strings for property-names.

What's wrong with strings? Just because it doesn't have three levels of
objects on it, doesn't mean it's not OK to use it.

> We now have static property-references, which means the codebase can be

If you know the property, you can just access it, you don't need to
invent weird indirection for it.

> Are we really going to quibble about syntax? This adds nothing to this

We're going to quibble about again trying to bring very small scope and
exotic feature into the core of the language.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #67232 — Adam Harvey — 2013-04-30T23:34:39+00:00

URL: https://externals.io/message/67147#67232 · In reply to: #67230

> At the risk of starting a separate discussion, the recently added
> ClassName::class constant provides a way to statically reference a class,
> which frankly has very few practical applications in comparison - the need
> to reference properties is usually much more prevalent and repetitive than
> the need to reference a class; assuming your classes have more than one
> property each, heh. The feature as such is also somewhat crippled, since
> what comes out of it is a string and not a class-reference.

I would caution against generalising use cases. Personally, ::class is
something I can use multiple times a day. This I'm not so sure about.

Your use case is not my use case, and vice versa. :)

> I think there is still a pretty strong case for static property-references,
> but since any new language-feature is generally a pretty hard sell around
> here, I'm letting this one go for now.

Why does this have to be a language feature? It obviously already
works in userland, as your own Symfony 2 examples show. One could
write a PropertyReference class right now with literally the only
difference being the lack of a builtin operator (ie new
PropertyReference($obj, 'prop') versus ^$obj->prop): the fact that
nobody seems to have done this in a major framework I know of suggests
that there isn't a strong need for encapsulating the indirection
beyond the $obj->$prop syntax that's worked forever.

Adam

---

## #67233 — Rasmus Schultz — 2013-04-30T23:35:31+00:00

URL: https://externals.io/message/67147#67233 · In reply to: #67231

I've already demonstrated and explained what's wrong with strings.

"Weird indirection" is what we have in every mainstream framework right
now, where properties can be referenced only as strings - I gave a
real-world example of this, and demonstrated with a practical example how
the proposed feature can help improve on this issue.

I've demonstrated by example that this has more than limited scope.

The fact that mainstream frameworks have to resort to strings for
property-references is a symptom of the fact that this feature is absent:

- Mainstream frameworks already do what I propose (using strings)
demonstrating that it is a necessary task.

- People use these frameworks - proving that developers want these features
from the frameworks they use.

Please, contribute something material to this discussion - your snappy
responses have to make me think you're taking this very personally?

I promise I'm not trying to ruin your day. Can't we just have a friendly
discussion like grown-ups?

On Tue, Apr 30, 2013 at 7:16 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > […]
>
> What's wrong with strings? Just because it doesn't have three levels of
> objects on it, doesn't mean it's not OK to use it.
>
> > […]
>
> If you know the property, you can just access it, you don't need to
> invent weird indirection for it.
>
> > […]
>
> We're going to quibble about again trying to bring very small scope and
> exotic feature into the core of the language.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #67234 — Sebastian Krebs — 2013-04-30T23:50:17+00:00

URL: https://externals.io/message/67147#67234 · In reply to: #67228

2013/5/1 Rasmus Schultz <rasmus@mindplay.dk>

> 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();
>

One problem I have with this example is, that you usually (or at least
often) don't have a "$task" object here.



>
> 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
> > […]
>
> > […]
> -
> > […]
>



-- 
github.com/KingCrunch

---

## #67235 — Rasmus Lerdorf — 2013-04-30T23:55:44+00:00

URL: https://externals.io/message/67147#67235 · In reply to: #67228

> 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.

The point is that there is no operator that fits and the reason you
didn't come up with one that didn't clash with something else. If this
can even be implemented, which doesn't seem all that certain without a
lot of messy changes, it should just be a reflection call.

-Rasmus

---

## #67236 — Rasmus Schultz — 2013-04-30T23:55:55+00:00

URL: https://externals.io/message/67147#67236 · In reply to: #67232

> I would caution against generalising use cases. Personally, ::class is
> something I can use multiple times a day. This I'm not so sure about.
>
> Your use case is not my use case, and vice versa. :)
>

What is your use-case then? DI perhaps?


> Why does this have to be a language feature?
>

I already covered that.


> It obviously already works in userland, as your own Symfony 2 examples
> show.
>

As explained, this is not intended to solve a problem that can't currently
by solved by other means, but to strengthen the static aspects of the
language.


> One could
> write a PropertyReference class right now with literally the only
> difference being the lack of a builtin operator (ie new
> PropertyReference($obj, 'prop') versus ^$obj->prop): the fact that
> nobody seems to have done this in a major framework I know of suggests
> that there isn't a strong need for encapsulating the indirection
> beyond the $obj->$prop syntax that's worked forever.
>

Look at the Symfony form-builder example - encapsulating the indirection is
*precisely* what they're doing: the object reference is stored in the
form-builder, and property-names are added subsequently.

Yes, you can already create property-references at run-time - for that
matter, you could already use new ReflectionProperty($obj, 'prop') to do
what you demonstrated above.

But the property-name, in the source-code, is a string - it has no literal
relationship to YourClass::$prop where as ^$obj->prop does.

No mainstream framework provides a PropertyReference class, because it
wouldn't accomplish anything - the property-name is still a string, it's
still unchecked, and still can't (reliably) be used in static analysis.

---

## #67237 — Rasmus Schultz — 2013-05-01T00:00:55+00:00

URL: https://externals.io/message/67147#67237 · In reply to: #67234

>
> one problem I have with this example is, that you usually (or at least
> often) don't have a "$task" object here.


I get what you're saying, but you do have a $task object if you want to use
the form-builder, because it relies on the object for state.

The same is true for most frameworks, and not generally a problem, since
you can just create a transient (throw-away) object - this generally works
fine, and has the added benefit of being able to initialize object
properties with defaults. (such as today's date on a calendar entry form)

On Tue, Apr 30, 2013 at 7:50 PM, Sebastian Krebs <krebs.seb@gmail.com>wrote:

>
>
>
> 2013/5/1 Rasmus Schultz <rasmus@mindplay.dk>
>
> > […]
>
> One problem I have with this example is, that you usually (or at least
> often) don't have a "$task" object here.
>
>
>
> > […]
>
>
>
> --
> github.com/KingCrunch

---

## #67238 — Rasmus Schultz — 2013-05-01T00:17:16+00:00

URL: https://externals.io/message/67147#67238 · In reply to: #67235

Okay, that is a technical/implementation problem - and I'm not the guy who
can answer than question.

I was thinking there might be a mathematical (or other) operator that
doesn't work without something in front of it to operate on, and I chose
the ^ operator based on a wild guess, plus the following:

> php -r "var_dump(4 ^ 8);"

int(12)

> php -r "var_dump(^ 8);"

Parse error: syntax error, unexpected '^', expecting ')' in Command line
code on line 1

> php -r "$foo = ^ 8;"

Parse error: syntax error, unexpected '^' in Command line code on line 1


I don't know the parser guts, but I figured since using the ^ operator with
nothing to operate on, causes a parser-error, that means the parser knows
that this is currently *not* valid syntax? Which might mean that there's a
way to turn this into valid syntax? I don't know.

I also figured the ambiguity with a bitwise operator is minimal damage -
bitwise operators are not one of the most commonly used features in
high-level languages.

If the asterisk (or some other character) offers and easier implementation
path, whatever.




> 
> > […]
> sake
> > […]
>
> The point is that there is no operator that fits and the reason you
> didn't come up with one that didn't clash with something else. If this
> can even be implemented, which doesn't seem all that certain without a
> lot of messy changes, it should just be a reflection call.
>
> -Rasmus

---

Next page: https://externals.io/message/67147.md?page=2