Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
Received-SPF: pass (google.com: domain of adamjonr@gmail.com designates 10.60.2.162 as permitted sender) client-ip=10.60.2.162;
MIME-Version: 1.0
In-Reply-To: <CAMyk_AZEs=GC6qe3rABbmc3HDFcBcSGhwPQ-UqBppTENq=+kRA@mail.gmail.com>
References: <CAJzDObfZpPCBc18pTOyxT8aCLzp801Vg9L_uj9HR=gg5geGKLQ@mail.gmail.com>
	<CAMyk_AZbuBYaDKigKxCSCP0=VNJPHJSNsicjVyDm78nJe2LMwA@mail.gmail.com>
	<CAJzDObeGJqtU2FdyfcdNdUO=eeXg6mOZ7iycbqwqH8unD_KxeQ@mail.gmail.com>
	<CAMyk_Ab3LO9erovz9XgF5q6ephm0=P3oGEKiqLCrKhk9d7bx7g@mail.gmail.com>
	<CAJzDObcoCsAYUxEoYBkkro4HSeN7ytd=4or3h-cZwzTzFqo2vg@mail.gmail.com>
	<CAMyk_AZEs=GC6qe3rABbmc3HDFcBcSGhwPQ-UqBppTENq=+kRA@mail.gmail.com>
Date: Thu, 1 Mar 2012 13:32:12 -0500
Message-ID: <CAJzDObcQeHqE53N7KD20-vt1XYcbvgVkfMrTVmyOOUV1p4TzXQ@mail.gmail.com>
To: Lazare Inepologlou <linepogl@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8f83a7d7b1d29504ba32ad28
Subject: Re: [PHP-DEV] Scalar Type Intentions
From: adamjonr@gmail.com (Adam Jon Richardson)

--e89a8f83a7d7b1d29504ba32ad28
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou <linepogl@gmail.com>wrote:

> Of note, the scalar type hinting I've outlined does not automatically
>> perform casts...
>
>
>  Thank you for your answer. Maybe, this exact fact is what I don't like
> about your suggestion. Please read the following RFC, where Lukas Smith and
> Zeev Suraski explain very well why strict type checking without
> auto-casting is a not a great idea. Of course it is just an RFC, but I find
> it quite correct.
>
https://wiki.php.net/rfc/typecheckingstrictandweak


I believe we interpret that RFC differently. Those who wrote it can correct
me if I'm in error. The RFC is a very interesting approach to providing
some form of type hinting for scalar parameters in functions and methods. I
liked the RFC, but I understand some of the concerns that come up when
discussing something like it.

First, I believe that when the RFC contrasts strict and weak typing, it
would be fair to say this is what many others would describe as strong vs
weak typing:

http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing

The RFC makes the case that strict typing is "is an alien concept to PHP",
and that it "goes against PHP's type system", while pointing out other
issues. The RFC makes it clear that trying to map strict typing onto PHP is
problematic, and on this issue I tend to agree.

The RFC then offers three options for weak type hinting. One main point I'd
bring out for all of the options is that they all strengthen the typing
(that is, while still a weak type system, it moves slightly towards the
strong side of the continuum) beyond PHP's default type juggling rules
because some type of error would be raised in the event of data loss.

So, their proposal outlines weak forms of type hinting for scalars, and
mine is similar but weaker, as there is no auto casting, there are no new
errors raised for data loss, and all checks are against the generic scalar
type (whether with or without the aliases.) This brings my proposal even
closer to the fundamental typing characteristics of PHP, whilst protecting
against the potential errors pointed out in my earlier examples.


>
> My concern is that if your suggestion is adopted (as it is, without
> auto-casting) then an eventual introduction of auto-casting will be
> impossible without breaking BC.
>

This is a potential concern if the aliases for scalar were included (bool,
int, float, string), as Anthony mentioned, although merely implementing the
first part of the proposal (scalar type hinting) wouldn't cause any trouble.

However, the more a proposal moves away from PHP's current typing
conventions, the less likely it is to be considered, let alone approved.
I'm not confident a more aggressive proposal (e.g., auto-casting with
checks for information loss) would be approved any time soon. PHP is one of
the most practically oriented programming languages I'm aware of, and my
practicalities just want to put forward ideas that improve some issues AND
that might actually get done :)

Again, thanks for the commentary, Lazare.

Adam

--e89a8f83a7d7b1d29504ba32ad28--