On 07.07.2009, at 00:55, Paul Biggar wrote:
Hi Lukas,
On Mon, Jul 6, 2009 at 11:03 PM, Lukas Kahwe
Smith<m...@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
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
