On 27 May 2010 12:14, Zeev Suraski z...@zend.com wrote:
BTW - even if strict type checking was implemented, do you truly think
people won't simply cast their inputs to make PHP shutup about 42 not
being a valid int? Let me assure you, they would. You'd gain nothing - as
a matter of fact
On 27.05.2010, at 14:31, Richard Quadling wrote:
In any decent course regarding defensive programming, we are told to
filter input and escape output. One easy way of filtering input is to
cast and verify.
Once cast and verified we know we've got the right type and acceptable values.
In
On Thu, 27 May 2010, Richard Quadling wrote:
On 27 May 2010 12:14, Zeev Suraski z...@zend.com wrote:
BTW - even if strict type checking was implemented, do you truly think
people won't simply cast their inputs to make PHP shutup about 42 not
being a valid int? Let me assure you, they
At 15:31 27/05/2010, Richard Quadling wrote:
On 27 May 2010 12:14, Zeev Suraski z...@zend.com wrote:
BTW - even if strict type checking was implemented, do you truly think
people won't simply cast their inputs to make PHP shutup about 42 not
being a valid int? Â Let me assure you, they
Hi!
What we are talking about here is an **optional** feature for user-land
function that allow the author to implement really cheap input-validation to
facilitate ensuring that the correct input is supplied. Additionally it also
It's not really optional - if you use a library that does
Hi!
It's exactly correct. Function declarations are a contract, just like
interface specifications. Not a let's pass some random stuff past
customs to see if it works. Having this, in combination with the
Yes, it's exactly how PHP functions and operators always worked - let's
accept
Hi!
*We* don't force anybody. API developers *could potentionally* force
their consumers to take care about their types.
Which is IMO bad idea. Having dynamic language means you care about the
data, but not its internal representation. Now you are stepping back and
telling them you need not
I have posted a topic on main Russian site for IT. Soon we will have a
result on what the Russian community thinks on this matter.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2010-05-27, Zeev Suraski z...@zend.com wrote:
I'm strictly against having two solutions. It's the worst outcome we
could reach IMHO - it means we're unable to decide which is better,
so we support both (kind of like a hi-tech version of
http://bit.ly/9I8dHw). I think it's the one
+1 vote for weak typing.
I myself often (but not always) do take care about types, so for me
personally strict typing won't hurt that much. However, I beleive this will
be an overcomplicated aspect to many. As we know, there are tons of
webmasters who dont know any programming language in deep -
The problem is that, as was pointed out, strict typing is not optional.
The minute I am using one library that is built with strict typing,
all of my interaction with it from my code must be strict. That means
either:
1) My application needs to be strictly typed throughout (assuming I even
On Thu, 27 May 2010, la...@garfieldtech.com wrote:
The problem is that, as was pointed out, strict typing is not
optional. The minute I am using one library that is built with strict
typing, all of my interaction with it from my code must be strict.
That means either:
1) My
On Thu, 27 May 2010, Arvids Godjuks wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't
On 27.05.2010, at 17:40, Derick Rethans wrote:
On Thu, 27 May 2010, Arvids Godjuks wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual
On Thu May 27 11:22 AM, David Soria Parra wrote:
On 2010-05-27, Zeev Suraski z...@zend.com wrote:
+1 from me for this. I think two solutions is not the right way and we
+should
try to make the type system consistent for the user. Therefore +1 for
auto-converting.
I still feel the debate of
Hi!
No, your app doesn't need to be. Only if you interact with a library
that employs it in the API. A library provides APIs. API developers that
want you to follow strict types now, will force you to do so anyway, but
What would be a legitimate reasons for API developers to care about zval
On Thu, May 27, 2010 at 5:47 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote:
well most people do not use that since its just as tedious to use as having
to cast your results. of course if we did have strict typing it would
probably become more widely used, not that having to add those lines
Hi,
I have only recently started listening in on this list and I usually
find it quite interesting. This one especially so.
But I think it's going nowhere...forgive me for saying so. I believe
that those of you, who'll have a say in this decision, have already made
their minds up and they
On 05/25/10 13:05, Thomas Nunninger wrote:
- If you don't want to distinguish beetween strict and weak hints, create
some
ini setting that influences the behavior. (I'm not a fan of that.)
My £0.02 as a user: ini settings should NEVER influence the way the core
language works, as they can
At 15:05 25/05/2010, you wrote:
I don't know if I have a full understanding about zval.type on internal
C-level. But in my code I always use strict type checking in comparisons and
in functions like in_array that offer that possibility. That's because I
learned the hard way how much debugging
hi Zeev,
On Wed, May 26, 2010 at 8:05 PM, Zeev Suraski z...@zend.com wrote:
I'd say: the type-juggling is not the *big plus* of PHP. BTW: if I read
some PHP is so enterprise-ready articles, I never read about the
advantages
of weak types. (I'd even liked it, if there would be an optional(!)
At 21:12 26/05/2010, Pierre Joye wrote:
As PHP's type system is seen as a big plus,
I have to say that many users consider it as a plus in the
implementation of a given method function or method. But the same
users ask to have something more strict for the methods signature. I
think it is a
On Wed, May 26, 2010 at 9:08 PM, Zeev Suraski z...@zend.com wrote:
At 21:12 26/05/2010, Pierre Joye wrote:
As PHP's type system is seen as a big plus,
I have to say that many users consider it as a plus in the
implementation of a given method function or method. But the same
users ask to
On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
At 21:12 26/05/2010, Pierre Joye wrote:
As PHP's type system is seen as a big plus,
I have to say that many users consider it as a plus in the
implementation of a given method function or method. But the same
users ask to have something more
Davey Shafik wrote:
Do you propose to have a warning when the types are a mis-match, similar to the
array-scalar conversion example from Gustavo? (strtoupper(array('ABC')))
If you have a warning or notice, that warns of potential loss of data accuracy,
then
I think I'd be OK with
At 23:44 26/05/2010, Davey Shafik wrote:
On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
At 21:12 26/05/2010, Pierre Joye wrote:
As PHP's type system is seen as a big plus,
I have to say that many users consider it as a plus in the
implementation of a given method function or method. But
On May 26, 2010, at 5:20 PM, Zeev Suraski wrote:
At 23:44 26/05/2010, Davey Shafik wrote:
On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
At 21:12 26/05/2010, Pierre Joye wrote:
As PHP's type system is seen as a big plus,
I have to say that many users consider it as a plus in the
Hi!
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
/.../
Why bother with either if that's the case? Why not add support for something
like:
Indeed, why bother? Only reason I heard so far is documentation. Which
applies to both cases, but as you
I like the idea of type hinting a lot. (See:
http://marc.info/?l=zend-engine2m=102421231114377w=2) I suggested it
in 2001 when ZE2 was being designed. Somehow my idea was bastardized
into only classes and arrays. Guess it was the mad OOP craze of the time.
Anyhow, I would like to use it. And,
On Wed, 26 May 2010, Davey Shafik wrote:
Would it be possible to support two syntaxes:
function foo( (int) $bar) { } // auto-cast to int
function foo(int $bar) { } // require int
I think that's a brilliant plan. We won't ever agree on whether we want
either strict type hinting, or
Hi,
On Thu, May 27, 2010 at 00:30, Derick Rethans der...@php.net wrote:
On Wed, 26 May 2010, Davey Shafik wrote:
Would it be possible to support two syntaxes:
function foo( (int) $bar) { } // auto-cast to int
function foo(int $bar) { } // require int
I think that's a brilliant plan.
On May 26, 2010, at 5:20 PM, Zeev Suraski wrote:
At 23:44 26/05/2010, Davey Shafik wrote:
On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
At 21:12 26/05/2010, Pierre Joye wrote:
As PHP's type system is seen as a big plus,
I have to say that many users consider it as a plus
On Wed, 26 May 2010 23:30:27 +0100, Derick Rethans der...@php.net wrote:
On Wed, 26 May 2010, Davey Shafik wrote:
Would it be possible to support two syntaxes:
function foo( (int) $bar) { } // auto-cast to int
function foo(int $bar) { } // require int
I think that's a brilliant plan.
Hi!
Let's call this proposal what it is -- strict typing. The auto-cast is (1)
mere fog in this discussion and (2) useless.
(1) fog
function foo( (int) $bar) {}
foo($bar);
is exactly the same, with strict typing, as
function foo(int $bar) { }
foo( (int) $bar);
No it is not the same.
At 00:28 27/05/2010, Davey Shafik wrote:
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
as:
function foo($bar) {
if (!is_int($bar)) {
// error
}
}
Why bother with either if that's the case?
I don't think there's any
Hi,
another end-user perspective:
Am Montag, 24. Mai 2010 14:12:41 schrieb Zeev Suraski:
At 14:48 24/05/2010, s...@geleia.net wrote:
Adding strict typing would be the largest
inconsistency in PHP's core syntax, ever.
I disagree. The === operator already checks the type of the
On 24 May 2010 13:09, Zeev Suraski z...@zend.com wrote:
I see three key options going forward:
1. Implement the table along the lines of what it looks like now, perhaps
with minor changes.
2. Implement identical conversion rules to the ones that exist in PHP; That
effectively turns type
On Mon, May 24, 2010 6:09 am, Zeev Suraski wrote:
At 03:53 24/05/2010, s...@geleia.net wrote:
On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
On Sat, May 22, 2010 at 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider
strict type
On Mon, May 24, 2010 at 1:48 PM, s...@geleia.net wrote:
I think the best option is to align the type checking with
zend_parse_parameters (this is not the same as an implicit cast) and make
it stricter. This includes:
* disallow string to float/int when it contains non-numeric characters
At 14:48 24/05/2010, s...@geleia.net wrote:
Adding strict typing would be the largest
inconsistency in PHP's core syntax, ever.
I disagree. The === operator already checks the type of the variables.
We can agree to disagree regarding the level of understanding the
average PHP developer has
On Mon, May 24, 2010 1:12 pm, Zeev Suraski wrote:
Sounds acceptable to me, that's along the lines of the 3rd option
which appears to be getting the most traction. I'd also no conversion of
arrays to scalars to that list.
Arrays to scalars already fail. See
Hi Zeev:
On Mon, May 24, 2010 at 08:09:30AM +0300, Zeev Suraski wrote:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in PHP;
That effectively turns type hinting into scalar
At 18:39 24/05/2010, Daniel Convissor wrote:
On a side note, I hope the hinting will allow the ability to do something
something like int|null for graceful handling of optional parameters.
There was an idea to allow null if you use 'int foo = null' - but
only that particular use case (e.g.,
Stas Malyshev wrote:
Hi!
I see three key options going forward:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
PHP; That effectively turns type hinting into scalar casting
Hi!
In case we remove 'Array-scalar' and others everywhere, #3 would be the
same as #2. I'm for that.
AFAIK parse_parameters already rejects Array-scalar, so if we can tweak
it so that it would make sense for all cases, even better.
As for implicit/explicit casts, I'm not sure - it might make
On 23 May 2010 07:52, Larry Garfield la...@garfieldtech.com wrote:
On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote:
At 01:01 23/05/2010, Hannes Magnusson wrote:
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
On Sun, May 23, 2010 at 7:52 AM, Larry Garfield la...@garfieldtech.com wrote:
Everything that comes back from a database does
so as a string. To wit: [...]
This is not entirely true though. mysqlnd will return native types
through PDO or mysqli if you use prepared statements [1] and hopefully
Hi!
I agree. function foo(array $x) {} foo(123); doesn't cast int(123) to
array(123) so introducing different meaning for scalar types feels
very very wrong.
Casting integers to arrays never happened in PHP. Casting strings to
integers and back always happened. Including in internal
On Sat, May 22, 2010 at 06:30:15PM +0200, Josh Davis wrote:
On 22 May 2010 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider strict
type checks completely alien to and counterintuitive in PHP and am therefore
pushing to implement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote:
any mistmatch results in an error
An error that is recoverable. So not only is the strict typing
optional, but type mismatches can be caught and handled.
-BEGIN PGP SIGNATURE-
Version: GnuPG
On 23.05.2010, at 14:44, Sebastian Bergmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote:
any mistmatch results in an error
An error that is recoverable. So not only is the strict typing
optional, but type mismatches can be caught
On May 23, 2010, at 8:51 AM, Lukas Kahwe Smith wrote:
On 23.05.2010, at 14:44, Sebastian Bergmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote:
any mistmatch results in an error
An error that is recoverable. So not only is the
On Sat, May 22, 2010 at 6:09 PM, Zeev Suraski z...@zend.com wrote:
I encourage everyone to take another look at this RFC even if you've read
it before.
Thanks,
Zeev
Hi internals,
Last time Zeev wrote an RFC for type hinting, I was (as a user) all for it.
This time is no different.
At 16:10 23/05/2010, Davey Shafik wrote:
We also already have a precedent for type-caring functions in the
ctype_* functions:
$ php -r 'var_dump(ctype_digit(123), ctype_digit((string) 123));'
bool(false)
bool(true)
There's a very specific reason for this behavior - ctype treats
numeric
Hello,
On Sat, May 22, 2010 at 17:04, Zeev Suraski z...@zend.com wrote:
All,
As I mentioned numerous times scalar type hinting is a very controversial
feature in my mind and requires some substantial discussion before we move
ahead to implement it.
As such, I think we should revert the
On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
On Sat, May 22, 2010 at 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider
strict type checks completely alien to and counterintuitive in PHP and
am therefore pushing to implement
On Monday 24 May 2010 12:09:30 am Zeev Suraski wrote:
I have to say that I don't really see the logic in either it should
be identical to PHP's conversion rules or it should be 100.000%
different (strict). Adding strict typing would be the largest
inconsistency in PHP's core syntax, ever.
Hi!
I see three key options going forward:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
PHP; That effectively turns type hinting into scalar casting
operators (not saying that's
Hi!
any mistmatch results in an error
An error that is recoverable. So not only is the strict typing
optional, but type mismatches can be caught and handled.
Unfortunately, PHP doesn't have good means to handle such kind of
errors. Global shut up handler is not a good means, as it
All,
As I mentioned numerous times scalar type hinting is a very
controversial feature in my mind and requires some substantial
discussion before we move ahead to implement it.
As such, I think we should revert the patch that was committed to
trunk and move to discuss it first instead.
My (
FYI - I did some fairly major editing on the issues with strict type
hinting and advantages of auto-converting type hinting in the RFC
(beforehand I focused primarily on the conversion table).
I encourage everyone to take another look at this RFC even if you've
read it before.
Thanks,
Zeev
Zeev,
First of all as far as I can tell majority of the changes relate to 2 new
type hints you are suggesting to introduce which are numeric and scalar. I
don't see any issue with adding those two hints, predominantly for people
who don't want to be specific with their type requirements. So, +1
At 19:30 22/05/2010, Josh Davis wrote:
On 22 May 2010 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider strict
type checks completely alien to and counterintuitive in PHP and
am therefore
pushing to implement 'weak' typing instead,
At 19:25 22/05/2010, Ilia Alshanetsky wrote:
Zeev,
First of all as far as I can tell majority of the changes relate to
2 new type hints you are suggesting to introduce which are numeric
and scalar. I don't see any issue with adding those two hints,
predominantly for people who don't want to
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
really cool, juggles strings with ints and what not. However, the
topic here is the _type hinting system_. As far as I know, there's no
weak type hinting; if a method signature hints
need to make sure we have a good structured discussion
(and documented via RFC).
Andi
-Original Message-
From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
Sent: Saturday, May 22, 2010 1:39 PM
To: Josh Davis
Cc: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] Type
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
really cool, juggles strings with ints and what not. However, the
topic here is the _type hinting system_.
On 23.05.2010, at 00:01, Hannes Magnusson wrote:
can we please just stop calling a something a type hinting system, which
leads to a catchable fatal error when the type does not strictly match?
thats a very misleading euphemism. its simply strict typing, it has nothing
to do with hinting.
need to make sure we have a good structured discussion
(and documented via RFC).
Andi
-Original Message-
From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
Sent: Saturday, May 22, 2010 1:39 PM
To: Josh Davis
Cc: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV
At 01:01 23/05/2010, Hannes Magnusson wrote:
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
really cool, juggles strings with ints and what not. However,
On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote:
At 01:01 23/05/2010, Hannes Magnusson wrote:
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
This sounds very similar to preconditions in Design by Contract. However,
preconditions validate input to the method as a whole, while the proposed
syntax only checks individual arguments one at a time. Thus the proposed
syntax has rather significan limitations compared to real preconditions.
For
On Fri, July 10, 2009 10:50 am, Alban wrote:
Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
And
On Tue, July 21, 2009 11:22 am, Christian Schneider wrote:
Richard Lynch wrote:
I think anybody who is coding with strict/weak/contract
type-enforcement/casting is going to understand
try/catch/Exceptions...
I'm not going to start an pro/contra Exceptions rant but *please* keep
Exceptions
Richard Lynch wrote:
I think anybody who is coding with strict/weak/contract
type-enforcement/casting is going to understand
try/catch/Exceptions...
I'm not going to start an pro/contra Exceptions rant but *please* keep
Exceptions out of the core language itself, that's a line we should not
hi,
I'm still in favour of #2 (Ilia's patch) as I don't see a real benefit
of a weak typing implementation, it defeats the main goal of this
addition. I'm also still opposed to add such thing in 5.3.x.
Cheers,
On Thu, Jul 9, 2009 at 9:47 AM, Zeev Suraskiz...@zend.com wrote:
2. Move forward
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
2009/7/10 Ionut G. Stan ionut.g.s...@gmail.com
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
On Fri, Jul 10, 2009 at 01:35:45PM +0300, Ionut G. Stan wrote:
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would
2009/7/10 Alain Williams a...@phcomp.co.uk
On Fri, Jul 10, 2009 at 01:35:45PM +0300, Ionut G. Stan wrote:
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x)
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function
Le Thu, 09 Jul 2009 21:11:31 +0200, Geoffrey Sneddon a écrit :
On 9 Jul 2009, at 18:20, Lukas Kahwe Smith wrote:
On 09.07.2009, at 10:39, Paul Biggar wrote:
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. If people here find it
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on Strict / Weak question.
It is really about:
* type checking and enforcement
or
* type casting and generation of an error if the value cannot be converted
cleanly
Both of these have a
Please let me state that this is the greatest idea I read since the type
hinting discussion began (and the only one I personally like, as I find all the
other proposals really disappointing).
+1.
This contract system seems to be the best by far.
--
PHP Internals - PHP Runtime
Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful
Alban wrote:
I don't understand why you focus on Strict / Weak question.
For me it's very simple, it's not obligatory use Type Hiting. Developpers
wants to write a weak code, they'll just have to not use Type Hiting and
developpers wants wrote a stric code they'll have to use it.
After,
On Fri, Jul 10, 2009 at 01:40:47PM +0200, Lukas Kahwe Smith wrote:
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
Just to add a little fuel to this fire, should we allow the specification of
return
type of functions, eg:
function int Factorial(int $num) {...}
What about things that return FALSE on error, eg fgets(), something like this:
function (string, bool) fgets(resource $handle, int
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on Strict / Weak question.
It is really about:
* type checking and enforcement
or
* type casting and generation of an
2009/7/10 Alain Williams a...@phcomp.co.uk:
Just to add a little fuel to this fire, should we allow the specification of
return
type of functions, eg:
function int Factorial(int $num) {...}
What about things that return FALSE on error, eg fgets(), something like this:
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on Strict / Weak question.
It is really about:
* type
On 10.07.2009, at 17:16, Alain Williams a...@phcomp.co.uk wrote:
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit
And Exception is better than an Error because this give one chance to
programmer for resolving the
At 10:42 10/07/2009, Pierre Joye wrote:
hi,
I'm still in favour of #2 (Ilia's patch) as I don't see a real benefit
of a weak typing implementation, it defeats the main goal of this
addition. I'm also still opposed to add such thing in 5.3.x.
Can you elaborate on what is the main goal of this
Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on
On Fri, Jul 10, 2009 at 11:50:04AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit :
The GET argument, yes, should be an integer, but it's possible is not !
In this, actually i always use this syntaxe :
is_child(intval($_GET['age']));
or
is_child( (int)
-- Forwarded message --
From: troels knak-nielsen troel...@gmail.com
Date: Fri, Jul 10, 2009 at 2:12 PM
Subject: Re: [PHP-DEV] Type hinting - Request for Discussion
To: Lukas Kahwe Smith m...@pooteeweet.org
On Fri, Jul 10, 2009 at 1:40 PM, Lukas Kahwe Smithm...@pooteeweet.org
*You* do the above because you know that you should; (hopefully you do
other checks as well). One of the things that we are doing is trying to help the
naive/lazy programmer who doesn't bother - or thinks that javascript checking
is enough :-(
What we want to do is to generate an
On Fri, Jul 10, 2009 at 06:10:33PM +0200, troels knak-nielsen wrote:
So you suggest the following goals:
Move common validation code out of the function body in order to
* reduce code
* increase readability
* enable IDE's to be even smarter.
Also it will improve reflection, this could be
Hi!
According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the
101 - 200 of 596 matches
Mail list logo
