Subclassing return values in 7

Derokorian

Can someone explain to me why I can change the actual return type to be a sub class, I can't declare it as such:

Declare it returns a sub-class, get a Fatal:

[derokorian@localhost ~]$ php
<?php
class Foo {
   static function get() : Foo {
      return new Foo();
   }
}
class Bar extends Foo {
   static function get() : Bar {
      return new Bar();
   }
}        

$b = Bar::get();

// Fatal error: Declaration of Bar::get(): Bar must be compatible with Foo::get(): Foo in - on line 11

Actually return a subclass, but declare the parent, works fine:

[derokorian@localhost ~]$ php
<?php
class Foo {
   static function get() : Foo {
      return new Foo();
   }
}
class Bar extends Foo {
   static function get() : Foo {
      return new Bar();
   }
}
$b = Bar::get();
var_dump($b);

// object(Bar)#1 (0) {
// }

Is this standard in OO languages?

Edit: I've done some additional looking around, and it seems this is called Covariant Return Types and was specifically disallowed by the RFC adding return types.

sneakyimp

Man I don't know why you might be doing that but I don't even understand the syntax in that second example.

Have you ever tried

return new static();

Derokorian

Yes, of course. Return static in this particular example would be exactly the same as what's happening now, but in reality I wasn't trying to return for the class I'm in. Instead, I have a base Collection class that implements Countable and Traversable, and when I subclass it to be a collection of a specific type, I can't declare add($item) or current() to accept/return the specific type of this collection.

IE, something like:

class UserCollection extends Collection
{
   public function add(User $item)
   {
      parent::add($item);
   }
   public function current() : User
   {
      return parent::current();
   }
}

This would make the contract more reliable, as I know the UserCollection would only ever hold and return User objects, instead I don't extend current at all and it has no return type, and my add looks like this:

   public function add($item)
   {
       if($item instanceof User) {
           parent::add($item);
       } else {
           throw new \InvalidArgumentException('Only User may be added to '. __CLASS__);
       }
    }

But the first post was just a trivial example where I wasn't trying to make a whole bunch of classes to show the point. The point is I can return a sub-type but not declare it as such (declaring return types is a php7.0 thing). But that was a stipulation of the RFC, so its possible we'll get covariant return types in the future.

laserlight

sneakyimp wrote:
Man I don't know why you might be doing that

In languages that are more statically typed, it can avoid unnecessary casts. For example, consider this C++ class hierarchy:

class X
{
public:
    // C++ quirk: destructors for polymorphic base classes are usually declared
    //            virtual to avoid undefined behaviour on delete of a derived
    //            class object via a base class pointer
    virtual ~X() {}

// A virtual clone function to mimic a virtual copy constructor:
virtual X* clone() const
{
    // Return a pointer to the cloned object:
    return new X(*this);
}
};

// Y is a subclass of X
class Y : public X
{
public:
    virtual X* clone() const
    {
        // Safe upcast from pointer to Y to pointer to X:
        return new Y(*this);
    }
};

If you had an object of class Y and wanted to clone it, having a pointer to Y point to the cloned object, it would be necessary to downcast:

Y y;
Y* p = dynamic_cast<Y*>(y.clone());

whereas if you make use of covariant return types:

class Y : public X
{
public:
    virtual Y* clone() const
    {
        return new Y(*this);
    }
};

You don't:

Y* p = y.clone();

Of course, in this example Y's copy constructor is still part of the public interface so one could invoke it directly, but such an alternative is not always readily available, so in general the notion of covariant return types in such languages is useful.

That said, Derokorian's example is news to me: because of the C++ (and Java) experience I picked up after learning PHP, I expected overriding to apply to non-static methods only, i.e., if you define a static method of the same name in a subclass, it would be overloading that hides the base class' version rather than overriding. If so, then the lack of covariant return types would not matter. However, the error message demonstrates that it is an override instead, hence the return type must match (or be covariant in some future version of PHP).