Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44894
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain giacobbi.net from 95.110.130.42 cause and error)
Date: Fri, 10 Jul 2009 12:23:02 +0200
To: troels knak-nielsen <troelskn@gmail.com>
Cc: internals@lists.php.net
Message-ID: <20090710102302.GC20283@gerbil.thgnet.it>
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> <98b8086f0907091150r47e7a103jaa50fcf7d5b32186@mail.gmail.com> <4A568B33.9000501@gmail.com> <98b8086f0907091744w7ab598dckc427d0a9484664b2@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <98b8086f0907091744w7ab598dckc427d0a9484664b2@mail.gmail.com>
User-Agent: Mutt/1.4.2.2i
Subject: Re: [PHP-DEV] Type hinting - Request for Discussion
From: giovanni@giacobbi.net (Giovanni Giacobbi)

On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
> 
> For example, instead of:
> 
>     function addFive(int $x) {
>       return $x + 5;
>     }
> 
> You would simply do:
> 
>     function addFive(is_numeric $x) {
>       return $x + 5;
>     }
> 
> Since $x is guaranteed to be numeric, it is safe to to arithmetic on
> it. No reason to explicitly type cast here.
> 


Please let me state that this is the greatest idea I read since the type hinting discussion began (and the only one I personally like, as I find all the other proposals really disappointing).

I'd like to see some real debating about this syntax proposed by troels:

function addFive(is_numeric($x)) {
  ...
}

Because I really like the idea of passing other parameters:

function check_multiple($a, $b) {
  return !($a % $b);
}

function doSomething(check_multiple($a, 3)) {
  // assume that $a is a multiple of 3
}


This solves all the problems I've understood so far:

- BC breaks for new reserved keywords 'int', 'float', ...: there is no need for them anymore

- weak typing vs strict typing:
    function cast_bool(&$value) { $value = (bool) $value; return true; }
    function weak_type_hinted(cast_bool($a)) { /* assume that $a is bool, no fatal errors */ }

- Nullable values:
    function is_int_nullable($val) { return is_int($val) || is_null($val); }
    function int_or_null(is_int_nullable($a)) { /* either $a is int or it's null */ }

- This will also make the error handling consistent where the classic type hinting wouldn't cover a particular use case:

 function foo(int $a) { ... }
 function bar($b) {
   if ($b is not appropriated parameter)
     trigger_error("Invalid parameter");
 }

 // a type of error (E_RECOVERABLE or TypeCheckException or whatever)
 foo("inappropriate_parameter");

 // a custom error, which might be *slightly different* from the one generated by the inner php engine
 bar("another_inappropriate_parameter");


I think this gives the perfect freedom to the developers and makes everyone happy. I know your concerns about third party libraries that you might have to deal with, but if you trigger one of those errors, then it means you are not respecting the APIs, which means there is a bug in your application.


-- 
Giovanni Giacobbi