Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B806A48BEC0C@MAILR001.mail.lan>
References: <CAJWj5+EwBpeMV__6SN7NbzQ0y4=RDGyg_HueU4N4AZz3Kb=CRQ@mail.gmail.com>
 <CADyq6sL2zbnqcYLpc7UrctPqdK+5TYztytKCxjdVUqUidsRN2g@mail.gmail.com> <A633CF2D7C7BED41B41F1E64F25507B806A48BEC0C@MAILR001.mail.lan>
Date: Sun, 18 Mar 2012 06:46:15 +0100
Message-ID: <CADyq6sL98YGoXzt7tOGrXJuQNMvBZB-THZs+ygd6a4c+r4q4Zg@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: Simon Schick <simonsimcity@googlemail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf303f6d2202b0e304bb7df78a
Subject: Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
From: ocramius@gmail.com (Marco Pivetta)

--20cf303f6d2202b0e304bb7df78a
Content-Type: text/plain; charset=UTF-8

Thank you for clarifying some things :)


>    4. Strict weak type hinting:
>
> This realm is the most likely to succeed because the core already does
> something like this for internal functions (via zend_parse_parameters).
> This balances utility (enforcing the type) with fundamental language design
> principles (juggling). You need to understand the fundamental language
> principles to understand why any solution MUST lie somewhere in this realm.
> Remember that:
> 1.2 === "12";
> "2"+"2" === 4;
> substr(12345, "2") === "345";
>
> This type juggling affects the language in all sorts of ways. For example,
> PHP uses '.' for concatenation (not '+' like most similar languages) which
> ensures that there is no ambiguity as to whether you are operating against
> the integer value or the string value. PHP is designed so that you
> generally don't have to care whether a value is ACTUALLY an integer or a
> string internally, it will be treated as whatever type you use it as. In
> PHP int(2), float(2.0), and string("2") can generally be used completely
> interchangeably with no variation in results whatsoever. When core devs say
> that "strict typing would make it not PHP anymore", this is what they mean;
> it would badly violate this core concept. If you want scalar typing, you
> need a solution that embraces this fundamental design principle.
>
>
Yeah, I don't want to start a discussion on that now nor start a (probably
already repeated) war on it, but I think those principles are dead since
very long time...


> >    5. Boxing based type hinting:
>
> This is a hack that's been proposed before, but you don't need to look
> very far to see why this ultimately breaks down badly. Even aggressive
> casting additions to the language would not make this work particularly
> well. Anyone who's ever tried to create a class wrapper for a scalar in C++
> (which probably includes the core devs) is not likely to be down with this
> idea.
>
>
That's not about working with scalar wrappers (which, anyway, would be very
useful in Doctrine). It is about casting any object to array... `((int)
$dbTableGateway)` could implicitly cause an sql `COUNT` query and stuff
like that :) Maybe I'm too java-ish, but those look like good improvements
to me :)

--20cf303f6d2202b0e304bb7df78a--