Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44858
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <7.0.1.0.2.20090709121921.0ae17d58@zend.com>
Date: Thu, 09 Jul 2009 12:46:28 +0300
To: Paul Biggar <paul.biggar@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <af54caaf0907090139q23a5574fscdcf29321c7f8f0e@mail.gmail.co
 m>
References: <7.0.1.0.2.20090708224156.0ac5a438@zend.com>
 <af54caaf0907090139q23a5574fscdcf29321c7f8f0e@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Type hinting - Request for Discussion
From: zeev@zend.com (Zeev Suraski)

At 11:39 09/07/2009, Paul Biggar wrote:
>I believe nearly all opinions voiced have wanted the current patch.
>Many more were in favour of strict typing only, but for the few
>dissenters, like myself, Ilia included casting semantics using (int)
>syntax.

I think that many of the people who expressed=20
support for that patch did not fully realize its=20
implications - much in the same way they weren't=20
quite realizing they're actually voting for=20
inclusion in PHP 5.3.  I believe that if we had a=20
'clean' Weak typing RFC as well as a Strict=20
typing RFC, each with its pros and cons - there=20
would be very different results.

>There are I think maybe 5 or 6 people who have expressed opinions
>against this. All others have been pro (I'm not counting the vote
>here, I'm looking at discussions).

I think you're right, but I also think it had to=20
do with dynamics more than with actual content.
The two approaches were never compared=20
head-to-head, with the pros and cons - and more=20
importantly - with use cases on why strict typing=20
is necessary despite the fact it's fairly 'alien' to PHP.

> > 2. =C2 Make sure people understand *why* we're=20
> implementing it - performance is
> > certainly *not* the reason.
>
>I believe there was only two misguided souls who believed this would
>lead to better performance. Everyone else wanted it on its merits.

Maybe - but the only way to make sure is to make it a clear part of the=
 RFC(s).

>It doesnt sound like you are aware of the casting semantics that Ilia
>added. They are largely consistent with the internal function
>semantics.
>
>function x (int x) { /* fail on non-int */ }
>function x ((int) x) { /* cast parameter to an int */ } // just like
>internals functions

I am - and I think I like this even less than=20
pure strict typing because of increased WTF factor.
I think strict typing is wrong for PHP, and this=20
cannot be fixed by also adding something=20
else.  The way to 'fix' this is by not adding=20
strict typing, and adding only weak typing.

>Indeed this adds the ability to make your function work like an
>internals function (useful perhaps for library interfaces).

If improved with slightly more intrusive checks=20
(like the ones suggested in my email) - then it=20
can be useful in mostly all of the places where strict typing would be used.

> > I think we can take Lukas's RFC and either change it or write something
> > based on it for weak typing only. =C2 If people here find it useful I'll=
 go
> > ahead and do that.
>
>I believe people don't want this. I wrote a set of rules, Lukas wrote
>the RFC, and neither got anything like the support that strict typing
>got.

This could be for a variety of reasons - one of=20
them is that people truly thought this through=20
and truly prefer strict typing to weak=20
typing.  But that is just one of the=20
options.  Another is that the difference between=20
the two approaches, as well as the issues with=20
strict typing - aren't fully understood by the=20
audience - and I believe that this is actually the case.

>One large problem is that it introduced a new 3rd set of rules, and
>this set is not intuitive but rather slightly subjective (reasonable
>people might disagree on whether a bool should be weakly converted to
>an int, for example). The strict type checks are at least simple, and
>the current weak ones are what people are used to.

I definitely don't think we should add two new=20
semantics.  Ideally we shouldn't add any=20
entirely-new semantics, and what I'm proposing is=20
to actually reuse the existing semantics for=20
internal functions - with very minor=20
modifications.  Kind of like Semantics and=20
Semantics', rather than Sematnics1, Semantics2, Semantics3.

>Obviously I'm not against discussion, but we just had this discussion.

Given the implications of introducing something=20
like that (that can easily grow in the future to=20
other parts of PHP) - and my belief that the=20
discussion missed key ingredients, we should discuss it further.

We need to go back to the fundamentals - and look=20
for use cases where strict typing would be=20
substantially superior to weak typing.  As far as=20
reflection, code readability, optimization and=20
security is concerned - I can't find any=20
superiority, but maybe I'm missing something.  We=20
already have an RFC that details the=20
disadvantages of strict typing (Lukas's=20
RFC).  Let's focus on the advantages and see if they're worth it?

Zeev