Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79220
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
Message-ID: <5476FE5A.20606@gmail.com>
Date: Thu, 27 Nov 2014 10:35:06 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFMT4Npco8sQ-+5hpUNa3pu5L2q7mnCVnsCjZee=NbNDrkwLUw@mail.gmail.com> <5474EF98.8070602@mabe.berlin> <CAFMT4NqThfke79_71cx1jACdb3dwgKRgvxZ6VqFtpNH5VycSkw@mail.gmail.com> <5474FF0C.4010405@mabe.berlin> <CAF+90c81zLAWvV9d5mgX1krjyvEpzZm_3MQvJ1gcbrGeKwRHaA@mail.gmail.com> <CAMyk_Aab41W2xiUxCY9dEoLemQJwUsFKKyOY=C1qRB02Jngo-w@mail.gmail.com>
In-Reply-To: <CAMyk_Aab41W2xiUxCY9dEoLemQJwUsFKKyOY=C1qRB02Jngo-w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
From: rowan.collins@gmail.com (Rowan Collins)

Lazare Inepologlou wrote on 26/11/2014 10:21:
> * Parameter types are contravariant, otherwise they are not type sound.
> Yet, contravariance in general is of little interest (I cannot think of any
> practical example), so invariance is a good compromise.

After reading the Wikipedia article, I've been thinking of some 
practical example of contravariance in PHP. One involves the Iterator 
and Traversable interfaces: imagine we have this class:

class Foo { public function iterate(Iterator $i) { /*...*/ } }

Now we make a sub-class which implements its iterate method using a 
foreach() loop, so can transparently accept any Traversable:

class Bar extends Foo { public function iterate(Traversable $t) { 
/*...*/ } }

This requires contravariance, because the child class accepts everything 
the parent class would, but doesn't have an identical type hint because 
it also accepts more.


A more involved example would be this:

// Two types of user, both extending a base class
abstract class User { abstract function getDisplayName(); /*...*/ }
class VisitingUser extends User { function getDisplayName() { return 
'Anonymous Coward'; } /*...*/ }
class RegisteredUser extends User { function getDisplayName() { /*...*/ 
} function getUserID { /*...*/ } /*...*/ }

// An interface for injecting observers of social events carried out by 
registered users
interface SocialEventListener { function handleUserEvent( RegisteredUser 
$u, Event $e ); }
// An implementing class can safely use methods only present for 
registered users without additional type checks
class UserTimelineWriter implements SocialEventListener { function 
handleUserEvent( RegisteredUser $u, Event $e ) { $user_id = 
$u->getUserID(); /*...*/ } }

// However, a more general observer might not use the user ID, and so 
could be reused for events with any kind of user
interface UserActionListener { function handleUserEvent( User $u, Event 
$e ); }
class EventLogger implements UserActionListener, SocialEventListener{ 
function handleUserEvent( User $u, Event $e ) { /* code relying only on 
$u->getDisplayName() ... */ } }

Without parameter contravariance, there is no way to achieve this. Since 
PHP doesn't have method overloading, you can't add a second version of 
handleUserEvent which accepts only RegisteredUser arguments, so you have 
to either change the name of the method in one of the interfaces, or 
create an entire adapter class just to change the type hint.


Obviously, the exact details here are contrived to make the point, but 
they don't seem all that far-fetched to me.

Regards,
-- 
Rowan Collins
[IMSoP]