RFC: remove restrictions from classes/interfaces/traits

[fredemmott]

Mostly inherited from PHP5, for example:

• can't put protected methods in interfaces
• can't do instanceof MyTrait

There are also restrictions we've added, eg interfaces can't require implements (#7353)[

While this is technically a BC break, it's only one in that it makes HHVM more permissive - i.e. it will make previously-invalid code valid. Precedent:

• we allow covariant return types and contravariant parameter types, PHP does not
• all the PHP7 features that are enabled in PHP5 mode

[fredemmott]

cc @dlreeves - I guess you've put more thought into this idea than me :)

[nikic]

What is the use-case for instanceof MyTrait? This seems like a code-smell indicating trait misuse.

[fredemmott]

trait Foo implements IFoo where Foo is the only thing that ever implements it is very common, at least in FB code.

As an added bonus, if the trait defines protected functions, the interface is often an empty marker interface given the second point, so no other implementations can ever be safe. The alternative is to define the methods as public, but that's often a worse tradeoff (though that statement is entirely subjective :) )

XHPAsync/XHPAwaitable in facebook/xhp-lib are one example of this.

[nikic]

In that case, would it also be possible to use class Foo implements FooTrait? I.e. use the trait as an interface. (Basically making a trait an interface with default implementation)?

[fredemmott]

'implements' pulling in code would be extremely surprising to me.

[nikic]

Not what I meant there -- rather you'd just get an interface with the trait methods. I.e. replace trait Foo implements IFoo with Foo acting both as trait and interface. But ... yeah, this is not a good idea, too confusing.

[fredemmott]

oh, so you meant a normal usage like:

class foo implements Trait {
  use Trait;
}

?

[fredemmott]

I guess you could make that more concise with:

trait TFoo implements TFoo {
}

But just removing the restriction seems more straight-forward and understandable

[nikic]

Another aspect to consider is how this interacts with trait conflict resolution. E.g. you can't do something like

interface I1 {
    function method(Sig1 $x);
}
interface I2 {
    function method(Sig2 $x);
}

class C implements I1, I2 { ... }

where I1::method() and I2::method() have the same name, but different signatures. However you can write something like this:

trait T1 {
    function method(Sig1 $x) {}
}
trait T2 {
    function method(Sig2 $x) {}
}

class C {
    use T1, T2 { T1::method insteadof T2; }
}

In this case C would be instanceof T2 (if the restriction is lifted), but C::method() would not actually conform to T2::method().

[fredemmott]

Ah, I forgot about that; that's banned in Hack, but to make sense with interop, this would also have to work with <?php files.

[jesseschalken]

@aorenste What is the PHP7 incompatibility here? AFAICT this issue is just an idea for loosening some restrictions.

[aorenste]

@jesseschalken I think it's me not completely reading the issue...