Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44734
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: PHP Internals <internals@lists.php.net>
Message-ID: <8A9581DA-2EFD-42E2-8628-659E757B90FE@pooteeweet.org>
To: Paul Biggar <paul.biggar@gmail.com>
In-Reply-To: <af54caaf0907061555o5ec48888ic07fa29b2c9245b3@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 7 Jul 2009 08:31:43 +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> <C161B45C-625A-40FD-A5B0-D0E633D31FCF@pooteeweet.org> <af54caaf0907061555o5ec48888ic07fa29b2c9245b3@mail.gmail.com>
Subject: Re: [PHP-DEV] weak and strict type checking RFC
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 07.07.2009, at 00:55, Paul Biggar wrote:

> Hi Lukas,
>
> On Mon, Jul 6, 2009 at 11:03 PM, Lukas Kahwe  
> Smith<mls@pooteeweet.org> wrote:
>> Ok, I have updated the RFC now with a table that shows that I  
>> expect to pass
>> and fail. Its fairly late, so I might have missed something. In  
>> general what
>> I am proposing is more lax than is_*() for the most part.  
>> Especially when it
>> comes to checking strings.
>
> I hope you have missed some things (or that they are typos) because
> otherwise a good chunk of this is plain lunacy.

Thank you for taking the time to review this. I am feeling kinda  
rushed here (I guess Ilia's call for votes proofs me right .. and  
apparently wrong at the same time).

> value string float int numeric scalar bool array
> 0 (integer) fail fail pass pass pass pass fail
> 1 (integer) fail pass pass pass pass pass fail
>
> 0 fails conversion to a float, but 1 and 12 succeed?

fixed.


> 12 (double) fail pass pass pass pass fail fail
>
> It may seem that this is a good idea (12.0 passing the int check), but
> what if 12.0 is OK, but 144.0/12 does not (which might not be 12.0 due
> to floating point error)?

right .. and the use case of this coming out of a config file is non  
existant. so that leaves the potentially slowly emerging use case of  
this coming out of a database and in this case people should just use  
the numeric check.

> '0' (string) pass fail fail pass pass pass fail
> '1' (string) pass fail fail pass pass pass fail

I presume you see the '0'/'1' pass as bools as lunacy. I disagree.

> '12' (string) pass pass pass pass pass fail fail
>
> Absolute lunacy. Please let this be a typo.

That part was indeed lunacy.

> '12.0' (string) pass pass pass pass pass fail fail
> '12.34' (string) pass pass fail pass pass fail fail
>
> As above.

Fixed as well.

> I think you need to present this information better. One advantage of
> Ilia's proposal is that it is very clear. It does two things: strong
> type check, or the same casts that currently exist. I think you need
> to say what changes you are introducing, and why they are introduced.
> The same flaw existed with my proposal: I dont think anyone wants a
> 3rd set of rules.

My proposals have a tendency to get this feedback. Probably because I  
write too much text and since I can also not produce a patch myself.  
Given that I have two large sections of text, one explaining the short  
comings of Ilia's approach and one explaining why I think that weak  
type checking solves this, I have taken this proposal as far as I can.  
If someone seems merit in it, please suggest improvements.

>> I do not understand why its suddenly so urgent to get this feature  
>> in(*),
>> that people already speak about frustration over the process after  
>> just a
>
> I think because this same issue has been going on for so long, and
> seem to be so very close now. This idea has been punted around in
> various forms and patches for years at this stage.

So the solution is to sneak it in during the summer, right after a  
major releases for which some have even delayed their vacations? Then  
again, given the fact that within a few hours this proposal has gotten  
5 +1, maybe I am being too paranoid .. well or Ilia is just doing a  
perfect job at orchestrating the masses. Either way we do not have  
processes for this .. so anything goes.

>> few days. We dont need years and usually not months, but this is  
>> not the
>> addition of some function. Its an extension to the language syntax,  
>> so I
>> think its totally normal that we talk about this for at least a  
>> month.
>
> Well yes. But with near consensus, there is a danger of a 90%
> good-enough patch being derailed by new proposals, and I get the
> impression most people would be happier with the 90% patch.

I have actually not felt much of an attempt to derail in the negative  
sense. But seeing that Ilia has labeled the "fairly detailed  
discussion" as "complaining for the sake of complaining" on his blog,  
I think that Ilia might be feeding this paranoia.

>> shouldn't we
>> rather talk about finding a better release process (maybe build on  
>> top of
>> recent developments in the version control world) that enables us  
>> to more
>> quickly get x.y releases out without preventing bigger features  
>> like unicode
>> from ever maturing?
>
> I've heard you mention this before. Please roll it into an RFC so we
> can think about it (FWIW, the idea that newer version control systems
> will somehow change everything makes little sense, so I think a lot of
> detail is required here).


Thanks.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org