Edit report at https://bugs.php.net/bug.php?id=64235&edit=1

 ID:                 64235
 Updated by:         dmi...@php.net
 Reported by:        imenem at inox dot ru
 Summary:            Insteadof not work for class method in 5.4.11
 Status:             Feedback
 Type:               Bug
 Package:            Scripting Engine problem
 Operating System:   Debian GNU/Linux
 PHP Version:        5.4.11
 Assigned To:        dmitry
 Block user comment: N
 Private report:     N

 New Comment:

Personally, I agree with deny_use_with_classes.patch


Previous Comments:
------------------------------------------------------------------------
[2013-02-21 09:09:56] larue...@php.net

The following patch has been added/updated:

Patch Name: deny_use_with_classes.patch
Revision:   1361437796
URL:        
https://bugs.php.net/patch-display.php?bug=64235&patch=deny_use_with_classes.patch&revision=1361437796

------------------------------------------------------------------------
[2013-02-20 19:33:35] dmi...@php.net

I agree with Stefan.
I think we have to allow only trait names in context of "as" and "insteadof" 
statements. Stefan showed a simple workarounds for class names.
I don't think we should fix the behavior we had in early 5.4 versions by 
mistake.

------------------------------------------------------------------------
[2013-02-20 16:22:55] re...@php.net

currently using class in context of trait 'as' and 'inteadof'
didn't work most of the time (as the code below demonstrated, even after apply 
the patch
larucence attached). Only the use case of this bug report, it HAPPENED to work. 


To keep the BC of the problem reported, as I suggested in the previous patch we 
could 
mark it as deprecated in 5.4.

So forbid class in 'as' and 'insteadof' didn't break because most of them 
didn't even work.

in the case of parent class insteadof usage, the REAL need is avoid trait's 
method overwrite
the method inherited but not refer to parent class.

there is a really easy workaround: rename the conflict method as
a new one `Traits::method as _use_less` or something else, 
if we really need the method from parent.


<?php

class Standalone {
        function foo() {
                echo "I shouldn't been called";
        }
}

class GrandParent {
        function foo() {
                echo "GrandParent";
        }
}

class Parent extends GrandParent {
        function foo() {
                echo "Parent";
        }       
}

trait T {
        function foo() {
                echo "Trait";
        }
}

class Child extends Parent {
        use T {
                /* as */
                Parent::foo as bar;             // Child::bar() -> undefined 
method
                StandAlone::foo as bar; // Child::bar() -> undefined method
                StandAlone::foo as foo; // Child::foo() -> "Trait"
                GrandParent::foo as bar; // Child::bar() -> undefined method

                /* insteadof */
                Parent::foo insteadof T; // works by accident -> "Parent"
                GrandParent::foo insteadof T; // -> "Parent" but not "Grand"
                StandAlone::foo insteadof T; // ->"Parent"
        }
}

------------------------------------------------------------------------
[2013-02-20 14:40:32] larue...@php.net

@Stefan the current patch is allow use insteadof with classes (as the reporter 
said, it used to works), 

and forbid use "as" with classes (5.4.11 will result in an unexpected FATAL 
error "undefined method", which is very confused message), the new solution is 
trigger compiler ERROR

so, for the current patch, I think it is consistent with before, no need to be 
RFCed again.

however, if we decide to forbind using both 'as' and 'insteadof' with classes, 
that definitely need a RFC

------------------------------------------------------------------------
[2013-02-20 13:20:15] g...@php.net

Hi:

The `insteadof` and `as` operators where not intended to be used with classes.
The syntax is intended to convey that the use operation is refined by 
specifying how to 
resolve conflicts __between__ traits.
That's the idea at least.

My solution for the initial problem presented would be to provide a method such 
as follows in 
the TestChildClass:
  public function method() {
    parent::method();
  }

I understand that this is not ideal, and requires you to repeat yourself.
However, it is consistent in the sense that traits are traits and not classes, 
and both get 
mixed up as little as possible,

However, beside the academic notion of purity, I can see that 
`TestParentClass::method 
insteadof TestTrait;` is useful.
[I wonder whether `parent::method insteadof TestTrait;` should be supported as 
well.]


Laruence's example with `TestParentClass::method as methodParent;` is however 
problematic. 
Traits are not supposed to conflict with classes, but with traits. So, allowing 
the 
introduction of aliases for method of the super class seems to me as something 
that is 
problematic, because it mixes up the concepts.

If you need an alias for the method of a parent class, the classic way would be:

public function foo() {
  parent::bar();
}

No?


Well, that's my point of view.


So, from a practical point of view, referring to the parent (and only the 
direct parent) class 
in `insteadof` might be a useful/acceptable feature.
The use in conjunction with `as` seems to be something I would advocate against.
In either way, beside bugs that made this possible in the first place, I would 
consider both 
ideas as new features that need to be documented/discussed.

I thought that we had a test that only the traits listed in the `use` clause 
can be used for 
the `as`/`insteadof` operators, but that's either broken or not there, or a bug 
that was fixed 
in 5.4.11 as the original report suggests.
Therefore, from my perspective, 5.4.11 shows the behavior that's intended by 
the spec/RFC.

Best regards
Stefan

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=64235


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1

Reply via email to