Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44725
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Paul Biggar <paul.biggar@gmail.com>,
 PHP Internals <internals@lists.php.net>
Message-ID: <C161B45C-625A-40FD-A5B0-D0E633D31FCF@pooteeweet.org>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
In-Reply-To: <5E12256D-40D0-4115-91C6-B5C35ABBF10D@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 7 Jul 2009 00:03:48 +0200
References: <5A834C9A-6D1B-49B7-88E6-FF047B084AB6@pooteeweet.org>  <af54caaf0907040705x27ce9362v303ab74a5db62eb4@mail.gmail.com>  <9B8C39B7-A5F8-4E61-BD7E-2069E584290D@pooteeweet.org> <af54caaf0907041210o6f8798c9j2af7503edc3a517e@mail.gmail.com> <5E12256D-40D0-4115-91C6-B5C35ABBF10D@pooteeweet.org>
Subject: Re: [PHP-DEV] weak and strict type checking RFC
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 04.07.2009, at 22:08, Lukas Kahwe Smith wrote:

>
> On 04.07.2009, at 21:10, Paul Biggar <paul.biggar@gmail.com> wrote:
>
>> On Sat, Jul 4, 2009 at 7:12 PM, Lukas Kahwe =20
>> Smith<mls@pooteeweet.org> wrote:
>>>> I can't see the difference between your proposal and the =20
>>>> conclusion I
>>>> reached yesterday?
>>>>
>>>> (which was that there is a near consensus around strict checks by
>>>> default, with casts allowed with some syntax).
>>>
>>> Well to me it Sounded like you wanted to Rely on Standard Type =20
>>> juggling and
>>> what i am proposing is more strict than that. More over i am Not =20
>>> convinced
>>> that strict should Be the Default.
>>
>> I don't know what you mean by standard type-juggling. Your proposal
>> really does not outline what you want very much, just what you're
>> against. As for strictness, if your proposal suggests that strict
>> typing is the default, I cannot see where.
>
> I did Not specify what doesnt Match in the RFC. I will fix that =20
> omission on monday. I assumed it was clear that i tried to Provide =20
> Complete examples for what will Pass. So Passung a String with =20
> anything but 1 or 0 would Not Pass =E0 Bool Type check.

Ok, I have updated the RFC now with a table that shows that I expect =20
to pass and fail. Its fairly late, so I might have missed something. =20
In general what I am proposing is more lax than is_*() for the most =20
part. Especially when it comes to checking strings.

I do not understand why its suddenly so urgent to get this feature =20
in(*), that people already speak about frustration over the process =20
after just a few days. We dont need years and usually not months, but =20=

this is not the addition of some function. Its an extension to the =20
language syntax, so I think its totally normal that we talk about this =20=

for at least a month. Though we do not of course need a daily exchange =20=

of 100 emails about this in this period. Obviously things can still be =20=

refined after the commit, but we should stuff give everybody a bit of =20=

time to let this stuff sink in before we do the initial commit. Also =20
remember that plenty of people that contribute a fair bit to PHP =20
internals do not read internals actively every week. So again a month =20=

isn't such a bad idea to have between the initial proposal and a =20
commit of the feature.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

(*) even if the patch Ilia proposed doesn't break binary compatibility =20=

anymore, do we really want to start adding such stuff in 5.3.2? =20
shouldn't we rather talk about finding a better release process (maybe =20=

build on top of recent developments in the version control world) that =20=

enables us to more quickly get x.y releases out without preventing =20
bigger features like unicode from ever maturing?