Hi dmitry, 
  will you take a look please.

actually, I was looking into this,  I have thought the similar fix of you, but 
unfortunatly, it is wrong, thinking of this:

<?php
class TestParentClass
{
    public function method()
    {
        print_r('Parent method');
        print "\n";
    }
}

trait TestTrait
{
    public function method()
    {
        print_r('Trait method');
        print "\n";
    }
}

class TestChildClass extends TestParentClass
{
    use TestTrait
    {
        TestParentClass::method as methodParent;
    }
}

(new TestChildClass)->methodParent();
~

fix attached, which fix this bug, and trigger fatal error in compile time for the 
test script I pasted before.

Yet another traits mess :(
I suppose, it worked in 5.4.4 because of mistake.
RFC and traits documentation don't say if class names may be used in context of "as" and "insteadof" operators.

In my opinion, class names must not be used in contest of "as".
However, their usage in context of "inseadof" may make sense (I'm not sure).
Anyway, it has to be defined in documentation first.

insteadof and 'as' bother for traits, I thought after the trait refactor, it's 
works as expected.

If we keep 'insteadof' could been used for class method as feature I'm fine:0

It's hard to say what is expected :)
I thought only traits may be used in context of "insteadof", now I'm not sure.

I sent the question to Stefan Marr. Lets wait for his opinion.

form the context,  insteadof works at class make sense.

reeze, whatever the RFC is, your fix simply skip check for classes at all, which 
will make the test script I paste result in "FATAL ERROR, undefined method", that 
is not acceptable.

@laurence  the code you paste above works the same as before:
http://3v4l.org/UpMCW#v5411 that didn't break

After read some doc I assume class is not suitable in context of 'insteadof', 
so let's wait for Stefan or more discussion :)

reeze, *before* doesn't always means *RIGHT*.

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

@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

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"
	}
}

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.

Personally, I agree with deny_use_with_classes.patch

Is there going to be a follow up discussion regarding the necessity of repeating methods in case traits and classes collide?

Stefan mentioned: "I understand that this is not ideal, and requires you to repeat yourself", but I don't think that this statement grasps the magnitude of the problem. You bring up only simplest cases here - methods with no parameters. But in reality we, PHP users, write methods with fair amount of parameters and a lot of docblock text. Should we repeat it all? Traits are meant to decrease repetition, right?