it's always not allowed since php 5.2,  why are you thinking it worked once?

or you can change it to a feature request :)

The reason I "think" it did work, is because it is **currently** working on a production site with PHP 5.3.11.  And it **has** been working for over 2 years.

Oh, sorry I misunderstanded , assign to my self , should have Sth to do with a fix 
made by me

Actually, I think it's a improvement of PHP-5.4, this change is introduced by 
fixing this issue: https://bugs.php.net/bug.php?id=60573

before this, you declare 
class A implements IComparable{
	public function equals(self $other){
		return ($this->var == $other->var) ? 'equal' : 'different';
	}
}

actullay the self in here is A, not IComparable. 

but in the IComparable, the self means IComparable itsself.

In scrupulously, A is_a Icomparable, but not equal to Icomperable, what do you 
think? 

thanks

The rule was previously accepted as the type hints where simple syntactic check 
(basically string comparisons). This was wrong, and got fixed in 5.4.

You cannot use self/parent as type hints as they depend on the current type in a 
covariant fashion, and type hints need to be contravariant.

To explicit the problem in 5.3:

interface A { public function foo(self $a); } 
class B implements A { public function foo(self $a) { } }
class C implements A { public function foo(self $a) { } }


If B (and C) are  valid (per <php5.4 rules) implementations of A, it means that 
anything you are allowed to do on A should work on B (and C) (by Liskov's 
substitution principle)

now let's see:

function test(A $a) { $a->foo(new C); }

test(new B) will fail
test(new C) will work

A side effect from this fix is that the wrong typehint now fails with an error, 
since B/C are invalid implementations of A.

Just to make it clear, you can use self/parent as type hints, as long as the 
class they reference is right, for instance:

class A {
    public function foo(self $plop) { }
}

class B extends A {
    public function foo(A $plop) { }
}

class C extends A {
    public function foo(parent $plop) { } 
}

are all equally fine. since parent in C is A, and self in A is A.

I am in the unfortunate situation of agreeing that you are technically correct. 

But I must say that it makes using "self" as a typehint fairly useless in an interface. Now if I want to require that a method argument be same type as $this, I'll have to do it this way:

interface IComparable {
	public function equals($other);
}

class A implements IComparable{
	protected $var;
	function equals($other) {
		if(get_class($other)!== get_class($this)) throw Exception('wrong arg class');
		return $this->var==$other->var;
	}
}

And that will make the interface much less specific and strong.

You are confusing "specific and strong" with wrong. With self as a type hint, 
you make the type system unsound, which means that it will provide you with 
absolutely no (virtual) guarantees.

For example:
function isEqual(IComparable $a, IComparable $b) {
   return $a->equals($b);
}

even though the IComparable interface declares a equals function that takes a 
IComparable, this code is not valid if self typehints work the way you want.


Another design problem of your example is:

equals should be reflective, that is: $a->equals($b) should mean $b->equals($a); 
This fails to be the case if self typehints are possible:

class A extends IComparable {
   def equals(self $a) { return true; }
}
class B extends A {
   def equals(self $a) { return true; }
}
$a = new A; $b = new B;

$a->equals($b); // OK
$b->equals($a); // type error