Hi internals,
It seems that there is a bug in the way some callbacks are handled. For
instance:
array('B', 'parent::who');
Here, the classname 'B' will only be used for inheritance checks with
the current scope,
but the actual resolution will be made using the current scope, and
'parent::who'.
According to Marcus, this is wrong, so here is two patches (+ tests)
meant for HEAD [1]
and the 5_2 branch (>5.2.3) [2].
Thanks for your consideration.
Regards
1: http://patches.colder.ch/Zend/callbacks_HEAD.patch?markup
2: http://patches.colder.ch/Zend/callbacks_5_2.patch?markup
--
Etienne Kneuss
http://www.colder.ch
colder@php.net
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
It seems that there is a bug in the way some callbacks are handled. For
instance:array('B', 'parent::who');
I'm not sure such thing should be even supported. I.e. I'd expect it to
try and call method named 'parent::who' in class B, which would fail
since you can't define such method name. Is there any reason why anybody
would really need anything like this?
According to Marcus, this is wrong, so here is two patches (+ tests)
meant for HEAD [1]
and the 5_2 branch (>5.2.3) [2].Thanks for your consideration.
First part of the patch changes EG(scope) even though no actual call is
made. I don't think you should change globals if you are not intending
to use them. If some value is needed which equals to EG(scope) or other
value depending on context, I think you should do it with variable, not
change the global, if possible.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
It seems that there is a bug in the way some callbacks are handled.
For instance:array('B', 'parent::who');
I'm not sure such thing should be even supported. I.e. I'd expect it
to try and call method named 'parent::who' in class B, which would
fail since you can't define such method name. Is there any reason why
anybody would really need anything like this?
It's already supported, but buggy right now. I don't believe fixing it
for odd cases will bother anyone.According to Marcus, this is wrong, so here is two patches (+ tests)
meant for HEAD [1]
and the 5_2 branch (>5.2.3) [2].Thanks for your consideration.
First part of the patch changes EG(scope) even though no actual call
is made. I don't think you should change globals if you are not
intending to use them. If some value is needed which equals to
EG(scope) or other value depending on context, I think you should do
it with variable, not change the global, if possible.
EG(scope) is used by zend_u_fetch_class to get the parent/current class,
I'm only altering it temporarily before zend_u_fetch_class and restore
it after that, no harm done.
--
Etienne Kneuss
http://www.colder.ch
colder@php.net
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
EG(scope) is used by zend_u_fetch_class to get the parent/current class,
I'm only altering it temporarily before zend_u_fetch_class and restore
it after that, no harm done.
I was speaking about 5.2 patch, didn't check the HEAD one.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
EG(scope) is used by zend_u_fetch_class to get the parent/current
class, I'm only altering it temporarily before zend_u_fetch_class and
restore it after that, no harm done.I was speaking about 5.2 patch, didn't check the HEAD one.
Oh, I see now what you mean. I ported the patch to 5_2 with the
assumption that zend_lookup_class also used EG(scope), but in fact it
doesn't. I updated the patch[1] which now directly uses
calling_scope/ce_org instead of the current scope for parent/self
resolution.
I hope this one better fits your requirements.
Regards
1: http://patches.colder.ch/Zend/callbacks_5_2.patch?markup
--
Etienne Kneuss
http://www.colder.ch
colder@php.net
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
It's already supported, but buggy right now. I don't believe fixing it
for odd cases will bother anyone.
Well, I'm for one not sure that callback in form array('B',
'parent::foo') shouldn't error out instead (I know it works now, but it
never states in the docs it's legal and I don't think it was intended to
work). Otherwise next thing would be array('B', 'C::foo') and that'd be
a real mess.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
It's already supported, but buggy right now. I don't believe fixing
it
for odd cases will bother anyone.Well, I'm for one not sure that callback in form array('B',
'parent::foo') shouldn't error out instead (I know it works now, but
it
never states in the docs it's legal and I don't think it was intended
to
work). Otherwise next thing would be array('B', 'C::foo') and that'd
be
a real mess.
Seems to me that anybody who thinks they need this can lookup the
parent of B and construct the right array in the first place...
I'm sure the patch is nifty, but it seems better to me to just error
out as well.
What about array('B', 'self::foo') -- I can see how that's needed to
call the static method, I guess...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
What about array('B', 'self::foo') -- I can see how that's needed to
call the static method, I guess...
But that won't be different from just array('B', 'foo') so you don't
need self::...
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
What about array('B', 'self::foo') -- I can see how that's needed to
call the static method, I guess...But that won't be different from just array('B', 'foo') so you don't
need self::...
Duh.
Sorry.
I somehow had some imaginary instance of 'B' that was involved...
Got lost in the clouds thinking about who needs anything like this at
all.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Hello Richard,
the feature actually exists because we need array($obj, 'parent::func')
best regards
marcus
Thursday, May 31, 2007, 10:33:54 PM, you wrote:
It's already supported, but buggy right now. I don't believe fixing
it
for odd cases will bother anyone.Well, I'm for one not sure that callback in form array('B',
'parent::foo') shouldn't error out instead (I know it works now, but
it
never states in the docs it's legal and I don't think it was intended
to
work). Otherwise next thing would be array('B', 'C::foo') and that'd
be
a real mess.
Seems to me that anybody who thinks they need this can lookup the
parent of B and construct the right array in the first place...
I'm sure the patch is nifty, but it seems better to me to just error
out as well.
What about array('B', 'self::foo') -- I can see how that's needed to
call the static method, I guess...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Best regards,
Marcus
the feature actually exists because we need array($obj, 'parent::func')
Why/when do you need that?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
the feature actually exists because we need array($obj,
'parent::func')Why/when do you need that?
You'd probably do something along those lines if it were possible:
((ParentClass) $child)->virtualMethod();
If you prefer, s/You/One/
Regards,
Michael
You'd probably do something along those lines if it were possible:
((ParentClass) $child)->virtualMethod();
Looks like bad style to me - why not call child's method and it would,
if needed, pass control to parent?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
You'd probably do something along those lines if it were possible:
((ParentClass) $child)->virtualMethod();
Looks like bad style to me - why not call child's method and it would,
if needed, pass control to parent?
Or, if, for some reason, you need to bypass the child's method, and
call only the parent's method of the same name, why not just look up
the class->Parent and then use array(Parent, 'function')
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Stanislav Malyshev wrote:
You'd probably do something along those lines if it were possible:
((ParentClass) $child)->virtualMethod();
Looks like bad style to me - why not call child's method and it would,
if needed, pass control to parent?
yeah, although I could imagine a situation where your stuck needing to calling
parent::method() it smells like bad OO - the same kind of bad smell that people
have been told they should avoid when it comes to wanting static interface methods,
function signature changing, etc.
personally I don't mind the smells, I'm not from the straight-jacket OO side of the
street. that said I do feel consistency is a worthy goal and therefore it seems correct
to enforce straight-jackets all round - given the general direction/mindset of php's OO
functionality it seems that calling parent::method() from outside the relevant
$child->method() should be illegal inline with other 'strictness enforcements'.