Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58461
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
Received-SPF: pass (google.com: domain of linepogl@gmail.com designates 10.236.154.168 as permitted sender) client-ip=10.236.154.168;
MIME-Version: 1.0
In-Reply-To: <CAJzDObcQeHqE53N7KD20-vt1XYcbvgVkfMrTVmyOOUV1p4TzXQ@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> <CAJzDObcQeHqE53N7KD20-vt1XYcbvgVkfMrTVmyOOUV1p4TzXQ@mail.gmail.com>
Date: Fri, 2 Mar 2012 09:53:00 +0100
Message-ID: <CAMyk_AbNOvrokVLPxJUfepZNK0E-TgoXUHELoeoxsp5w-8Nfcw@mail.gmail.com>
To: Adam Jon Richardson <adamjonr@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3040eb9a617be004ba3eb522
Subject: Re: [PHP-DEV] Scalar Type Intentions
From: linepogl@gmail.com (Lazare Inepologlou)

--20cf3040eb9a617be004ba3eb522
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> This is a potential concern if the aliases for scalar were included (bool=
,
> int, float, string), as Anthony mentioned, although merely implementing t=
he
> first part of the proposal (scalar type hinting) wouldn't cause any troub=
le.
>

Yes, exactly. I was only talking about this specific aspect.

Otherwise, it is a fine and welcome proposal. I would love to have
type-checking as long as it does not close the door to type-juggling some
time in the future.


Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2012/3/1 Adam Jon Richardson <adamjonr@gmail.com>

> On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou <linepogl@gmail.com>w=
rote:
>
>> 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 f=
ind
>> 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 an=
d
> 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 typi=
ng
> (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 scala=
r
> type (whether with or without the aliases.) This brings my proposal even
> closer to the fundamental typing characteristics of PHP, whilst protectin=
g
> 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 t=
he
> first part of the proposal (scalar type hinting) wouldn't cause any troub=
le.
>
> 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 AN=
D
> that might actually get done :)
>
> Again, thanks for the commentary, Lazare.
>
> Adam
>

--20cf3040eb9a617be004ba3eb522--