But I just wanted to point out that this is something the author
(and I) would never expect to happen ...
in_array(123abc, array(3, 7, 123, 28)) === true
Well, would you never expect
select ( '123abc' in (3,7,123,28) )
to return boolean true in SQL?
Because it does.
Me, I'm happy with
Hello Simon,
in_array(123abc, array(3, 7, 123, 28)) === true
This is a pointless example, because the first argument of in_array is of
type mixed and not int. So, this may cause many headaches, but it is
irrelevant to the discussion about scalar type hints.
Lazare INEPOLOGLOU
Ingénieur
2012/3/18 John Crenshaw johncrens...@priacta.com:
2. Unenforced type hinting:
This almost happened in 5.4, but eventually got pulled. More interestingly,
the *community* rejected it because it is useless. See the comments at
On 3/17/2012 11:46 PM, Marco Pivetta wrote:
Thank you for clarifying some things :)
4. Strict weak type hinting:
This realm is the most likely to succeed because the core already does
something like this for internal functions (via zend_parse_parameters).
This balances utility (enforcing
2012/3/18 Simon Schick simonsimc...@googlemail.com:
2012/3/18 John Crenshaw johncrens...@priacta.com:
2. Unenforced type hinting:
This almost happened in 5.4, but eventually got pulled. More interestingly,
the *community* rejected it because it is useless. See the comments at
On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
simonsimc...@googlemail.comwrote:
Hi, All
Just to add an example why I want a more strictly type-check here as
we have in the current type-juggling:
2012/3/18 Adam Jon Richardson adamj...@gmail.com:
On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
simonsimc...@googlemail.comwrote:
Hi, All
Just to add an example why I want a more strictly type-check here as
we have in the current type-juggling:
On Sun, Mar 18, 2012 at 7:11 PM, Simon Schick
simonsimc...@googlemail.comwrote:
Hi, Adam
I totally agree that type-hinting should not cover what the programmer
should do for validating the given input ...
But I just wanted to point out that this is something the author (and
I) would never
tl;dr: strict type hinting and Boxing based type hinting (the second
one with some changes).
Just read through it, and I was unaware there's still ideas to continue
working on type hinting in PHP.
That's good news, at least for me :)
I'm just lurking around here, but if my thoughts can help, here
On Sat, Mar 17, 2012 at 10:37 AM, Marco Pivetta ocram...@gmail.com wrote:
Unenforced type hinting:
- If you have mixed types, then you just don't need type hinting. Lazy
devs can still avoid using it. Lazyness shouldn't really be
encouraged, so
providing some kind of backwards
From: Marco Pivetta [mailto:ocram...@gmail.com]
tl;dr: strict type hinting and Boxing based type hinting (the second one
with some changes).
Just read through it, and I was unaware there's still ideas to continue
working on type hinting in PHP.
There's been some recent discussion
Thank you for clarifying some things :)
4. Strict weak type hinting:
This realm is the most likely to succeed because the core already does
something like this for internal functions (via zend_parse_parameters).
This balances utility (enforcing the type) with fundamental language design
On Thu, March 8, 2012 5:13 am, Alain Williams wrote:
On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote:
Type hints are meant to
filter input from external sources
Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources
+1
What
Hi Simon!
2012/3/8 Simon Schick simonsimc...@googlemail.com:
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
I realize that with scalars it's not that straight
Type hints are meant to
filter input from external sources
Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 8, 2012 at 10:03 AM, Arvids Godjuks arvids.godj...@gmail.comwrote:
Hi Simon!
2012/3/8 Simon Schick simonsimc...@googlemail.com:
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I think Catchable fatal error should be fine and users are familiar with
such
On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote:
Type hints are meant to
filter input from external sources
Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources
+1
What they will do is to catch where input from external
2012/3/8 John Crenshaw johncrens...@priacta.com:
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I think Catchable fatal error should
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by the
type hint. If you send a string of characters and pass it to a int type
hinted function -
AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
solution for scalar type hints would be the unification of the scalar type
hints with the current implementation of zend_parse_parameters.
Yeah, that's basically what we were discussing. However, there's one
significant
On Thu, 08 Mar 2012 13:38:32 +0100, Anthony Ferrara ircmax...@gmail.com
wrote:
AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
solution for scalar type hints would be the unification of the scalar
type
hints with the current implementation of zend_parse_parameters.
2012/3/8 John Crenshaw johncrens...@priacta.com:
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by the
type hint. If you send a string of characters
Gustavo,
Not really, that's just a convention that if zpp fails functions return null
or false immediately (which one is used depends on the extension, current
weather, etc.). That's because there's a convention that builtin functions
don't raise exceptions. But nothings stops them from
Well, if your type hints gets more forgiving, than it's the same that was
proposed by this function a((int) $arg) {} And in this case hints have no
meaning at all - it's just other syntax to do the conversion that now looks
like this function a($arg) { $arg = (int)$arg; }
That's black and
On Thu, Mar 8, 2012 at 6:08 PM, John Crenshaw johncrens...@priacta.comwrote:
Well, if your type hints gets more forgiving, than it's the same that was
proposed by this function a((int) $arg) {} And in this case hints have no
meaning at all - it's just other syntax to do the conversion that
From: Adam Jon Richardson [mailto:adamj...@gmail.com]
I don't think it's fair to say that casting is too forgiving OR
that current sentiment is settling around behavior similar to the
internal zend_parse_parameters. This is a complex issue, and there
are many core developers who have been
Stas Malyshev wrote:
And can we please stop using word hinting?
We can call it type conversion, typecasting, type coercion, etc.
http://en.wikipedia.org/wiki/Type_conversion
But I don't see how there's any hinting involved.
Is this were things have drifted from the original working base? I
Hi,
I'm with Stas here.
First let me say that I would like to see type hinting for scalars in
PHP. As a userland developer it would help me to write clean and more
robust code. But I think this proposal is only a workaround to get a
round the main problem. It's a try to push similar
Stas,
Thanks for the comments!
inline.
On Wed, Mar 7, 2012 at 2:31 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and rather
confusing, I really wouldn't like to
Christian,
On Wed, Mar 7, 2012 at 3:22 AM, Christian Kaps
christian.k...@mohiva.com wrote:
Hi,
I'm with Stas here.
First let me say that I would like to see type hinting for scalars in PHP.
As a userland developer it would help me to write clean and more robust
code. But I think this
I, for one, decided not to participate in the discussions any more
because they always change to something different in a few hours of
discussion. I'm surprised how people tend to complicate the feature
into something weird and ugly. I now understand why core team just
ignores some discussions.
I
Comment in-line below...
On Wednesday, March 07, 2012 07:10 AM, Simon Schick wrote:
Hi,:
It got quite around that because we have some RFCs to this where the
functionality seems to be defined as the people thought it should be.
Otherwise they can raise their hands and write a mail that they
You could try some kind of stricter casting. Where odd conversions
between array/object - bool/int/float/string do not work on parameter
casting .. but then you end up with two types of casting ...
I have used in depth the casting operators of C#, which are incredibly
flexible and powerful, and
Hi!
would make even less sense, since it would need to be cast, so the
following would return false:
function foo((string) $bar = 123) {
return $bar === 123;
}
foo();
You explicitly said convert, then compare excluding conversion, what
would you expect? That's like saying why $a+1 is
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
John,
On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw johncrens...@priacta.com
wrote:
A good number of issues with the current proposal were raised during the
discussion on the mailing list. I don't feel like digging them all up right
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
I realize that with scalars it's not that straight forward, but
complicating things by adding an auto-cast syntax and so on
John,
Thanks a lot for the reply. Comments inline:
You've been spending a lot of time defending these proposals and trying to
prove wrong feedback that raises concerns. This is preventing you from
actually using the feedback to improve the proposals. You are losing out on
perhaps the
Hi,
Just a small addition to what I wrote about handling null ...
function foo(array $d = array()) { var_dump($d); }
foo(null); // This fails with the message: Argument 1 passed to foo()
must be an array, null given
As this code fails I'd not expect to change this behavior for the weak-types.
Now we understand each other fully...
Point taken.
I've withdrawn the parameter hinting RFC.
Thanks...and aw crap. I hate feeling like I shut the door on something.
Let's make sure we can salvage as much as possible here:
1. The structure of the patch looked like it was reusable
John,
Thanks...and aw crap. I hate feeling like I shut the door on something.
Not at all. I don't feel bad about this in the least. Yes, I would
have liked to have gotten it in, but I want a good solution before I
want mine. So I'm absolutely willing to withdraw this RFC, as it does
have
From: Simon Schick [mailto:simonsimc...@googlemail.com]
I consider interchangeable only three cases:
1. Numerical string.
2. Integers and floats as strings.
3. Integer and string 0 1 as bool.
Any other cases should error out.
Until now I thought about the weak variable-types
On 3/7/2012 8:48 PM, John Crenshaw wrote:
In fact, nearly every input to PHP is a string. This is why PHP was
designed with some seriously robust type juggling on scalars. Any
typing proposal that wants to actually pass a vote is going to have
to allow appropriate implicit conversions from
2012/3/8 John Crenshaw johncrens...@priacta.com:
Conversion the other way is essential. Consider the following URL:
http://example.com?foo=1
In your PHP script $_GET['foo'] === '1' (a string).
In fact, nearly every input to PHP is a string. This is why PHP was designed
with some
Hi,
It got quite around that because we have some RFCs to this where the
functionality seems to be defined as the people thought it should be.
Otherwise they can raise their hands and write a mail that they want to
update the RFC - but as there's no one doing that, I think we're quite
close to
My concern is the total lack of talk on-list about it. It's obviously
not perfect, but there has been little to no talk on-list about it.
That is an indication to me that it's not ready or that it won't get
in if put to a vote...
Thoughts?
Anthony
On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick
Personally, speaking for myself at least, I've quieted on the subject
temporarily in favor of advocating some improvements to the RFC voting
process that will ultimately make it easier for us to work through these
type hinting questions. I'll be resurrecting the discussion on this end
before too
Hi,
It got quite around that because we have some RFCs to this where the
functionality seems to be defined as the people thought it should be.
Otherwise they can raise their hands and write a mail that they want to update
the RFC - but as there's no one doing that, I think we're quite close
John,
Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote
consent in this case. I actually basically stopped participating when it
became apparent that people were determined to rush head first into creating
a doomed RFC without any process to ensure that historical
Disclaimer: The following is direct (maybe brutally so). I'm not trying to hurt
any feeling or attack, but I'm not pulling punches either. I don't have the
energy right now to polish this and make it all nice and gentle, so I'm sorry
in advance. I hope you'll look past the directness and be
John,
On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw johncrens...@priacta.com wrote:
Disclaimer: The following is direct (maybe brutally so). I'm not trying to
hurt any feeling or attack, but I'm not pulling punches either. I don't have
the energy right now to polish this and make it all nice
On 2012-03-06, Anthony Ferrara ircmax...@gmail.com wrote:
My concern is the total lack of talk on-list about it. It's obviously
not perfect, but there has been little to no talk on-list about it.
That is an indication to me that it's not ready or that it won't get
in if put to a vote...
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and
rather confusing, I really wouldn't like to have such syntax in PHP.
Also (int) $foo = “1” will generate an E_COMPILE_ERROR makes no sense
to me.
Also, this line:
Wow no offense, but your timing is terrible, Raymond! We've been going
back and forth on this for the past couple weeks now, though the discussion
has quieted for the moment.
I would suggest you go through some of the recent posts on Internals.
Right now there basically is no solid consensus on
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP
Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com wrote:
No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web
Secure code is not about the instrument, it's about how you write it.
Insecure spagetti code can be written in any language.
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency,
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
From: Simon Schick [mailto:simonsimc...@googlemail.com]
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or
E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at
If any of you are interested in such change in PHP, please get
together and write a complete RFC. As I do not see any kind of
progress but, as you stated, some philosophical discussions. That's
all good but after 2 weeks, it is time to move forward (or stop).
Cheers,
On Thu, Mar 1, 2012 at 4:02
Kris Craig wrote:
With all due respect, it's a logical fallacy to draw a direct comparison
between these two simply because they both happen to be uphill battles.
There is a direct comparison between the two. Both provide something that a
large number of people did not or do not want anything
That's what I was calling inconsistent, specifically because (int)'foo'
== 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an
error of some sort. Behavior with respect to when an error is raised is
inconsistent. In both cases there is a very lossy conversion, why is there
an
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimc...@googlemail.comwrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this
On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine les...@lsces.co.uk wrote:
Both provide something that a large number of people did not or do not
want anything to do with.
I disagree - The majority of PHP developers I've discussed this with are
in favor of adding *something *like this. Do a
Here's one thing to consider. Right now casting/type-autoconversion
is inconsistent at best. Let me show you what I mean:
If I add 1 to a variable, the variable is converted based on the
standard http://us2.php.net/manual/en/language.types.type-juggling.php
type juggling rules, but the variable
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard
@Lester Well there's another logical fallacy. How, exactly, am I trying to
force this on anyone? Last time I checked, the PHP community has a
voting process that requires a 2/3 majority for anything touching the
code. Also, last time I checked, there are numerous people who do want
this, so I
On Thu, 01 Mar 2012 20:51:17 +0100, Kris Craig kris.cr...@gmail.com
wrote:
@Lester Well there's another logical fallacy. How, exactly, am I trying
to force this on anyone? Last time I checked, the PHP community has a
voting process that requires a 2/3 majority for anything touching the
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if
From: Simon Schick [mailto:simonsimc...@googlemail.com]
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.comwrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu,
, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than
28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more
.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people
int $a = 1; // no error. 1 == 1 so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.
For the sake of consistency, please take into account this example, which
works in the current implementation of PHP:
$b = 1 + 1; // no error, $b == 2
$b = 1 + House; // no error,
I agree with Simon on this:
On Wed, Feb 29, 2012 at 08:58, Simon Schick simonsimc...@googlemail.com wrote:
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays) or
bind a variable to a strict type?
- should it then also be
On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for floor()
streak int $i = 123.456; //In contrast to previous
streak int $i =
[mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be
sellable
because some people on here have expressed
@Richard I think you made a very good point. Should we treat a float =
int mismatch the same as we would a string = int mismatch, or should the
former fail more gracefully? I can see good arguments for both.
--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch c...@l-i-e.com wrote:
On
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless of
what the incompatible type is. But in the case where a float might sneak
its way
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I think
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes
Hi, Kris
As we have some RFCs around that we should update them I think.
In my opinion we should split them up into 3 RFCs (and one grouping RFC):
Weak and strong type-checks (whatever that in detail means) should be
discussed in one single RFC. The option1 in the existing one is pretty
close
Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Err sorry yes John is correct. I wasn't paying close enough attention.
Here's *my* vision of how that progression would look:
$a = 1; // Current kosher unchanged.
weak int $a = 1; // Converts to 1. No error thrown
@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Err sorry yes John is correct. I wasn't paying close enough attention.
Here's *my* vision of how that progression would look:
$a = 1; // Current kosher unchanged.
weak int $a = 1; // Converts to 1. No error thrown.
strong int $a = 1
Personally, while I see the value in recycling what's already there, I
think that would just make things WAY more confusing than they need to be.
Some of these RFC's are years old and appear to have since been abandoned.
I think it would be better to have a procedure for removing dead RFC's
after
: John Crenshaw; Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Aand here we go again. Every few days it seems, somebody jumps into
this thread and reminds us that strict typing is a bad idea, despite the fact
that we've already all agreed on that point
Kris Craig wrote:
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I have to complain about that. There is nothing wrong in my
Guys, you probably are too deep into the discussion that you haven't
noticed an elephant Zeev has put into the room. When the RFC procces was
put in place there was a rule outlined - if core devs decide to reject,
it's rejected. And as Zeev said last time core dev team decided that there
will be
:* Kris Craig [mailto:kris.cr...@gmail.com]
*Sent:* Wednesday, February 29, 2012 11:18 PM
*To:* Zeev Suraski
*Cc:* John Crenshaw; Richard Lynch; internals@lists.php.net
*Subject:* Re: [PHP-DEV] Scalar type hinting
** **
Aand here we go again. Every few days it seems, somebody
Kris i have a question for you - who will implement a test patch? Previous
tries failed not because no one wanted, but because it was damn hard and
tricky. And ofcourse there was resistance against strict type hinting. Mine
included. I doubt any of the last timeinvolved will be willing to do that
: Thursday, March 01, 2012 12:16 AM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Responses inline.
--Kris
On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski
z...@zend.commailto:z...@zend.com wrote:
Kris,
If we've agreed
I would challenge the preconceived notion that it's likely to be rejected.
It winds up being a form of circular logic. For example, you argued that
previous tries failed to be approved because nobody wanted to do the work.
But then you said that nobody wants to do the work because it has failed
1 - 100 of 220 matches
Mail list logo
