On 1/10/2013 6:57 PM, Nikita Popov wrote:
Even more generic, we just could use existing ReflectionProperty like
this (this is standard API, no changes needed):
(new ReflectionProperty(get_parent_class(),
'foo'))->setValue($this, $val);
Yes, this is even more long-winded, that's why maybe we should have
shortcut function for it. Depends on how frequently in practice we
expect to do it.
I like this idea as a solution to the problem. It would be ideal if
parent::$foo would work but since that is not currently a reasonable
option, either leaving the user land programmer to use reflection to do
it or to provide them with a shortcut way to do it is a good interim
solution to the problem.
I'm not sure that we really even need a 'shortcut' to do it, we'd need
some other people to chime in on that and how often the parent accessor
would want to be called.
> I know that this is not an optimal solution, but I would much prefer
> this over some new syntax like "parent->foo". Once (if) static
I like this approach more too.
+1 as well
> properties have better engine support we can switch to the cleaner
> parent::$foo way. But until then I think that this is a good
compromise,
I'm afraid we couldn't though since parent::$foo already means
something
else - it's a static property "$foo" of the class that is parent of
current class. We could redefine it in this specific context, in
theory,
but that would be strange special case and I don't think it would be
good idea to do that. Our syntax kind of assumes the object has
only one
class and all properties belong to this class, so we don't have a
proper
syntax to express the idea of "same property, but with different
scope".
I try to see :: as a scope resolution operator rather than a static
access operator. For methods that's how it works (you can call
instance methods with it in a different scope, e.g. parent scope). So
doing the same for properties isn't far off. But yes, I do agree that
this would be rather tricky and could open another big can of worms
(like we have with method calls from incompatible contexts), so it
might not actually make sense to go down that path.
I agree with that general sentiment as :: as a scope resolution
operator, it's just that right now, for ::$ that always translates to
static property access which is the current conundrum.
> This is just a rough idea of what I'd do. The exact way this
would work
> still needs further discussion. E.g. one could make passing the
property
> name optional and assume the current property as default. Or one
could
If you assume current property you'd have to store it somewhere to
pass
it and have API for that function to extract it, which sounds like
very
tight coupling for this function. Maybe something like __PROPERTY__
would be better?
The current property can be obtained through
EG(current_execute_data)->function_state.function. This holds the
accessor function and the property can be taken from its name. Though
this is obviously all a bit dirty and is probably not a good idea.
Probably better to let people explicitly pass the property name.
Nikita
Is everyone okay with a long winded way to get/set the parent accessor
if necessary?
(new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val);
Alternatively, reflection in some cases takes an object instance
(ReflectionObject), we could extend ReflectionPropertyAccessor so that
it could take an object, then something that is slightly shortened would
work, like this:
(new ReflectionPropertyAccessor($this, 'foo'))->setValue(45);
That presently doesn't work, but could be made to work, especially
considering it's a new sub-class anyways.
If we don't like setValue() being different b/w ReflectionProperty and
ReflectionPropertyAccessor we could upgrade both classes to accept an
object instance as its constructor argument...
--
-Clint
