Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.206 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=AM8BKnlrYVaBa0Y8ujyjgN98AlDJeIgux4sc3hBKJTiru06twr/hZtRqxHH303CeVz
         h2kGfOX/+8t77c+TQLBRzHmb1tZ6jYB30ztzwpWmOY2CtpV7rdlFZOmVc+rqjKrkzNrB
         mxtih4cEAnzJA4zyVDE9jjdyJeL8+mZ8+6/5s=
MIME-Version: 1.0
In-Reply-To: <22CAD497EA2F476DAECEF9302D0B087A@pc>
References: <7.0.1.0.2.20090708224156.0ac5a438@zend.com>
	 <af54caaf0907090139q23a5574fscdcf29321c7f8f0e@mail.gmail.com>
	 <312025EF-84D0-4411-A0A7-4F0379C3105F@pooteeweet.org>
	 <af54caaf0907090932w2e5921e6l55f854ff80020dc8@mail.gmail.com>
	 <22CAD497EA2F476DAECEF9302D0B087A@pc>
Date: Thu, 9 Jul 2009 20:50:07 +0200
Message-ID: <98b8086f0907091150r47e7a103jaa50fcf7d5b32186@mail.gmail.com>
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Type hinting - Request for Discussion
From: troelskn@gmail.com (troels knak-nielsen)

Hi list.

In advance, sorry for muddying the waters even further.

Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]

Given the dynamic nature of php, I would suspect that it might be a
much better fit. Unlike the semi-static typecheck that typehints can
give, a contract system would be much more expressive and would add a
lot more value (in my opinion anyway).

I think part of the reason for the popularity of typehints is that it
looks familiar for people coming from Java/C++/C#. The biggest
challenge for such a contract system would then be to come up with
something that doesn't look too alien. A simple way that I can think
of is to overload the meaning of typehints so that they may either
denote a class/interface (as they work currently) OR they may be a
function which takes the variable as argument and yields a boolean.
Eg.:

    function array_of_numeric($x) {
      foreach ($x as $val) {
        if (!is_numeric($val)) {
          return false;
        }
      }
      return true;
    }

    class Foo {
      /** Example use-case for a contract */
      function sum(array_of_numeric $a) {
        return array_sum($a);
      }
    }

This is just one suggestion - There are other ways to implement the concept.

I can see a number of benefits to a contract system over the currently
discussed typehint system:

1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.

[1] http://docs.plt-scheme.org/guide/contracts.html

--
troels