On 20 Jul 2014, at 17:26, Theodore Brown theodor...@outlook.com wrote:
The one remaining issue I have with this proposal is that boolean values are
currently accepted for every other scalar type except array. As with NULL,
FALSE is a common error value, and allowing booleans to be passed to
Hi!
After consulting with Anthony about this, the RFC and patch have been
updated to disallow booleans for int, float, numeric and string type
hints. The conversions table now looks like this:
This makes very little sense, 0 means the same as false is in many
contexts in PHP and also in many
On 25 Jul 2014, at 20:20, Stas Malyshev smalys...@sugarcrm.com wrote:
This makes very little sense, 0 means the same as false is in many
contexts in PHP and also in many languages.
It also means very different things in some places, particularly return values.
strpos returning 0 is most
Hi!
The point of this RFC is to strike a compromise that is generally
useful rather than helping one specific use case (strict hints) or
another (casts).
What you call compromise is the inconsistency - it's not strict
typing, it's not weak typing, it's half that and half this without any
hi Andrea,
On Sun, Jul 13, 2014 at 3:57 AM, Andrea Faulds a...@ajf.me wrote:
Good evening,
PHP’s type hinting system is rather incomplete as it does not support
scalars, only arrays, callables and objects. In 2012, Anthony Ferrara created
an RFC which proposed type hinting for scalar types
The argument saying that it is not the PHP way is somehow incorrect
here, given that we already do that for classe. The type jungling
makes sense in implementations, as it always was but argument
passing
and validation have been a source of pain since very long. I could
imagine one exception
On Jul 24, 2014 10:34 AM, Patrick Schaaf p...@bof.de wrote:
The argument saying that it is not the PHP way is somehow incorrect
here, given that we already do that for classe. The type jungling
makes sense in implementations, as it always was but argument passing
and validation have
Hi,
there is, it seems, something missing from both the RFC and the
discussion, as far as I read it. Sorry if it came up before, it was a huge
amount of mails...
How does the proposal affect method compatibility between
subclasses and baseclasses? Will two methods there, differing in the
On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf p...@bof.de wrote:
Hi,
there is, it seems, something missing from both the RFC and the
discussion, as far as I read it. Sorry if it came up before, it was a huge
amount of mails...
How does the proposal affect method compatibility between
Hi!
I think it should behave like class arguments do.
That's called strict typing and was discussed many times. Do we really
want another round of repeating the same arguments?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime
On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf p...@bof.de wrote:
Hi,
there is, it seems, something missing from both the RFC and the
discussion, as far as I read it. Sorry if it came up before, it was a huge
amount
On Thu, Jul 24, 2014 at 11:03 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I think it should behave like class arguments do.
That's called strict typing and was discussed many times. Do we really
want another round of repeating the same arguments?
As I said, yes it was discussed, and
On Thu, Jul 24, 2014 at 11:03 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf p...@bof.de wrote:
Hi,
there is, it seems, something missing from both the RFC and the
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Thursday, July 24, 2014 12:04 PM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
That's called strict typing and was discussed many times. Do we
On Thu, Jul 24, 2014 at 12:25 PM, Zeev Suraski z...@zend.com wrote:
We definitely do not..
Well, open list, if some like to discuss it, we can. But see below, it
may not be necessary.
To elaborate, the notion that we already have strict class types for
classes, so we should have the same
My main concern about the RFC the way it stands right now is that the
current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST
for data loss. This results in both consistency issues with casting as well
as incompatibility with the dynamic nature of PHP scalars. I know the
On 24 Jul 2014, at 13:20, Simon Schick simonsimc...@gmail.com wrote:
Conversion is allowed only if data-loss does not happen. There are a few
exceptions (objects using __toString, strings containing leading numerics,
etc). Here's a table of examples.
But if you look at the table, strings
On 23 Jul 2014, at 19:37, Andrea Faulds a...@ajf.me wrote:
On 23 Jul 2014, at 19:21, Robert Williams rewilli...@thesba.com wrote:
Also, do int, float, and numeric accept numbers in octal, hex, scientific
notation, etc.? I don’t believe there are any examples in the RFC that
On 13 Jul 2014, at 02:57, Andrea Faulds a...@ajf.me wrote:
The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast
A pull request is here: https://github.com/php/php-src/pull/717
I just updated the patch and RFC to include overflow safety for the integer
type hint. This
On 24 Jul 2014, at 09:42, Patrick Schaaf p...@bof.de wrote:
How does the proposal affect method compatibility between subclasses and
baseclasses? Will two methods there, differing in the scalar type annotations
of one of their arguments, elicit STRICT warnings, like object type
On Jul 14, 2014, at 10:13, Andrea Faulds a...@ajf.me wrote:
We are using hack’s syntax (int, float, bool, string, no
integer/double/boolean aliases).
On 20 Jul 2014, at 14:11, Andrea Faulds a...@ajf.me wrote:
The patch actually warns you if you try to do this now:
function foo(double
On 23 Jul 2014, at 19:21, Robert Williams rewilli...@thesba.com wrote:
It seems odd to me to not support the aliases. Since I can do this:
$foo = (integer)$bar;
I would expect to be able to do this:
function foo(integer $param) {}
Aliases mean inconsistency. We shouldn’t
On Jul 23, 2014, at 11:37, Andrea Faulds a...@ajf.me wrote:
Aliases mean inconsistency. We shouldn’t unnecessarily have multiple names
for the same thing, just one. Also, for every alias we support, another
reserved word is added. Hence we only allow one set of names. This is also
On 23 Jul 2014, at 22:17, Robert Williams rewilli...@thesba.com wrote:
Although I don’t have voting rights, I would completely support a separate
RFC to remove the aliases in PHP 6/7. But in the mean time, as long as
they’re still in the language, I think they need to be fully supported
Am 13.07.2014 07:22, schrieb Stas Malyshev:
I think it was a mistake to introduce this term from the start and
we should stop propagating it.
What would be a better term? Optional strict typing in function and
method signatures?
--
PHP Internals - PHP Runtime Development Mailing List
To
On 20 Jul 2014, at 08:33, Sebastian Bergmann sebast...@php.net wrote:
Am 13.07.2014 07:22, schrieb Stas Malyshev:
I think it was a mistake to introduce this term from the start and
we should stop propagating it.
What would be a better term? Optional strict typing in function and
method
On 18 Jul 2014, at 14:09, Andrea Faulds a...@ajf.me wrote:
On 18 Jul 2014, at 06:02, Theodore Brown theodor...@outlook.com wrote:
Another concern I have is in regard to the future. I'm looking forward to
the
possibility of specifying nullable types in a future version of PHP (see
Levi
On 20 Jul 2014, at 14:11, Andrea Faulds a...@ajf.me wrote:
double
Did I just say double? I meant float, of course. :)
The patch actually warns you if you try to do this now:
function foo(double $foo) {}
foo(1.0);
If you use one of the non-existent aliases (double), and pass the type
On 14 Jul 2014, at 17:25, Anthony Ferrara ircmax...@gmail.com wrote:
And that also hints towards a benefit of adding a numeric hint as well
(which will accept (and cast to) either an int or a float, exactly how
is_numeric_string() does internally)... Which is something that may
want to be
2014.07.20. 14:43, Andrea Faulds a...@ajf.me ezt írta:
On 20 Jul 2014, at 08:33, Sebastian Bergmann sebast...@php.net wrote:
Am 13.07.2014 07:22, schrieb Stas Malyshev:
I think it was a mistake to introduce this term from the start and
we should stop propagating it.
What would be a
On 20 Jul 2014, at 15:54, Ferenc Kovacs tyr...@gmail.com wrote:
This proposal’s scalar type hints (except for booleans) can’t really be
called “strict”. Perhaps “firm typing”? (It’s not weak, but it’s not quite
strong either)
Stas and Sebastian are talking about the unfortunate naming
On 18 Jul 2014, at 14:09, Andrea Faulds a...@ajf.me wrote:
I’ve updated the RFC and patch to make int, string and double nullability
work like the other types (bool already did). If the default value isn’t
NULL, NULL isn’t accepted and you’ll get E_RECOVERABLE_ERROR. If the default
value
Hi!
What would be a better term? Optional strict typing in function and
method signatures?
Parameter typing, or typed parameters if you will. One of the options,
of course, there could be many others.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP
On Fri, Jul 18, 2014 at 7:02 AM, Theodore Brown theodor...@outlook.com wrote:
Since I am very much in favour of scalar type hints, I've updated the
patch to master and made some minor improvements, and I am re-opening
the RFC with the intent to try and get it into PHP 5.7.
First of all, this
On 18 Jul 2014, at 06:02, Theodore Brown theodor...@outlook.com wrote:
Another concern I have is in regard to the future. I'm looking forward to the
possibility of specifying nullable types in a future version of PHP (see Levi
Morrison's Declaring Nullable Types RFC:
Another concern I have is in regard to the future. I'm looking
forward to the possibility of specifying nullable types in a
future version of PHP (see Levi Morrison's Declaring Nullable
Types RFC: http://wiki.php.net/rfc/nullable_typehints). If the
nullable types RFC is accepted, it would be
Hi,
On 07/16/2014 10:45 PM, Andrea Faulds wrote:
On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:
anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.
Right, so it needs to be fixed. It makes no sense to force a new agenda
on the
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Wednesday, July 16, 2014 11:17 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Wed, Jul 16, 2014 at 09:31:46AM +0100, Rowan Collins wrote:
Now
Thomas Nunninger wrote:
- scalar parameter casting should just be a convenience for coding:
function foo( (int) $i, (string) $s )
{
}
is the same as:
function foo( $i, $s )
{
$i = (int) $i;
$s = (string) $s;
}
or perhaps better::
Hi Dan,
On 07/17/2014 02:12 PM, Dan Ackroyd wrote:
Thomas Nunninger wrote:
- scalar parameter casting should just be a convenience for coding:
function foo( (int) $i, (string) $s )
{
}
is the same as:
function foo( $i, $s )
{
$i = (int) $i;
- I'd like to have E_CAST on all castings/type jugglings even if we do
not get scalar type hinting.
$var = 6.3;
$a = (int) $var;
Or $b = (bool) 1;
This is usual code and it could be wanted to losse information on casting.
Triggering errors for that would be extremely annoying.
- I
Hi Thomas,
Perhaps I miss your point. But what is the difference to current behavior if
you do not know about the types?
Not to the current behaviour, to the behaviour that would be possible
with scalar type-hinting.
Or is your point about inspection of parameter type? Why shouldn't
Apologies, I pasted the wrong code, it should have read:
which makes the code:
function foo( $i, $s )
{
$i = (int) $i;
$s = (string) $s;
}
Not be equivalent to:
function foo( (int) $i, (string) $s )
{
}
As the type-hint information is not
Since I am very much in favour of scalar type hints, I've updated the
patch to master and made some minor improvements, and I am re-opening
the RFC with the intent to try and get it into PHP 5.7.
First of all, this is my first reply on PHP Internals so I hope I am doing it
right. :)
Thank
Andrey Andreev wrote (on 15/07/2014):
I'm sorry, I know what you mean here and I'm not criticizing you
specifically (in fact, I'm intentionally taking it ouf of context),
but that's PHP internals, not PHP community.
Point taken, but there's plenty of overlap between the two; it's not
like
On Wed, Jul 16, 2014 at 09:31:46AM +0100, Rowan Collins wrote:
Now, one form of compromise is to use variants of the syntax, such as...
function foo((int) $bar)
function foo(-int $bar)
...
A slight tangent, but *if* this sort of syntax is adopted we need to think what
will happen when
On Tue, Jul 15, 2014 at 11:05 PM, Andrea Faulds a...@ajf.me wrote:
On 15 Jul 2014, at 21:02, Andrey Andreev n...@devilix.net wrote:
Unless you really force the camps to pick one by saying you can't
have Y if we've got X (to which there's no technical limitation, so
that's not true)
No
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, July 15, 2014 7:14 PM
To: Rowan Collins; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Hi!
The answer - which is definitely a matter of opinion
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Tuesday, July 15, 2014 10:48 PM
To: Andrey Andreev
Cc: Rowan Collins; Stas Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 15 Jul 2014, at 20:43, Andrey
On Jul 16, 2014 4:29 PM, Zeev Suraski z...@zend.com wrote:
For me the introduction of a new set of rules is a deal breaker.
I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
implicit casts, plus change implicit casts to emit E_CAST in case of loss
of data or 'bogus'
Zeev Suraski wrote (on 16/07/2014):
For me the introduction of a new set of rules is a deal breaker.
I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
implicit casts, plus change implicit casts to emit E_CAST in case of loss
of data or 'bogus' conversions.
Just to be
Stas Malyshev wrote (on 15/07/2014):
Hi!
That's only a problem if you frame the new hints as a type of implicit
cast. If they were to be described in relation to existing
functionality, I'd describe them as a new type of *explicit* cast, but
How they are explicit cast if you're not explicitly
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com]
Sent: Wednesday, July 16, 2014 1:25 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Zeev Suraski wrote (on 16/07/2014):
For me the introduction of a new
Andrey Andreev wrote (on 16/07/2014):
I understand that this RFC is about type cast hints and that's fine
with me.
It is and it isn't. It's about a hybrid approach which deliberately
mixes casting and validation.
Having the mixture alongside pure casts or pure validation is less
attractive
Zeev Suraski wrote (on 16/07/2014):
Secondly, if you do enable E_CAST - you may have to slightly*modify* your
understanding of implicit casts, but you won't have to learn two different
sets of rules. New users will see just one consistent set.
I think I've got a bit lost: I thought you were
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com]
Sent: Wednesday, July 16, 2014 3:18 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Zeev Suraski wrote (on 16/07/2014):
Secondly, if you do enable E_CAST
Zeev Suraski wrote (on 16/07/2014):
But there too, they'd have consistency, just one set of rules for
implicit cast of scalar values across all of PHP.
The way I see it is that there's an existing set of rules for the result
of any cast, implicit or explicit; these are in some cases lossy.
On 16 Jul 2014, at 10:29, Zeev Suraski z...@zend.com wrote:
For me the introduction of a new set of rules is a deal breaker.
I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
implicit casts, plus change implicit casts to emit E_CAST in case of loss
of data or 'bogus'
On 16 Jul 2014, at 13:28, Zeev Suraski z...@zend.com wrote:
It's more of a lossy cast, exactly as we have today, that has an
(effectively-optional-since-it's-off-by-default) to warn you about loss of
data.
For the vast majority of users who use the defaults, there'll be nothing new
to learn
Hi!
As has been pointed out already, that would be inconsistent with
existing type hints. zend_parse_parameters emits E_WARNING and
returns FAILURE, while type hints raise E_RECOVERABLE_ERROR. To make
scalar type hints not emit E_RECOVERABLE_ERROR and instead do
something weaker would
On 16 Jul 2014, at 20:17, Stas Malyshev smalys...@sugarcrm.com wrote:
You say it as if it is an advantage. It is not. Having a rule that is
subtly different in 10% of places is actually worse than having one
totally different, because you start relying on it being the same, and
you don't
On Jul 16, 2014, at 7:03 AM, Andrea Faulds a...@ajf.me wrote:
On 16 Jul 2014, at 13:28, Zeev Suraski z...@zend.com wrote:
It's more of a lossy cast, exactly as we have today, that has an
(effectively-optional-since-it's-off-by-default) to warn you about loss of
data.
For the vast majority
On 15/07/2014 20:44, Andrea Faulds wrote:
PHP has pseudo-functions, maybe we could use that format? cast_int($foo)?
Actually, perhaps the solution is an ahead-of-time check:
if (safe_cast($foo, int)) {
$bar = (int!)$foo;
} else {
$bar = 1;
}
I think this
On 16 Jul 2014, at 20:47, Rowan Collins rowan.coll...@gmail.com wrote:
I think this would be quite nice - keeps things relatively short without
introducing so much punctuation that it starts looking like a Perl script ;)
The only problem is that either you need a whole set of functions
anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.
Right, so it needs to be fixed. It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the language. Align
your new feature to the rest of the language, not
On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:
anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.
Right, so it needs to be fixed. It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Wednesday, July 16, 2014 11:45 PM
To: Zeev Suraski
Cc: Stas Malyshev; Andrey Andreev; Rowan Collins;
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 16 Jul 2014
On 16 Jul 2014, at 22:10, Zeev Suraski z...@zend.com wrote:
Stricter typing does not belong in PHP. If it did, we'd have it in
internal functions, implicit casting and the rest of the language in
general. We don’t.
This proposal isn’t that much stricter than zpp, aside from booleans I
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Thursday, July 17, 2014 12:17 AM
To: Zeev Suraski
Cc: Stas Malyshev; Andrey Andreev; Rowan Collins;
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 16 Jul 2014
On 16 Jul 2014, at 22:42, Zeev Suraski z...@zend.com wrote:
That's the point. Many people will not consider this an error, myself
included, and I suspect that also Rasmus and Andi who created the language
concept for the language many many years ago. PHP doesn't consider it to
be an error
On 16/07/14 23:12, Andrea Faulds wrote:
As I’ve explained earlier, letting them choose to make this fatal would be a
horrible, horrible idea.
This is no worse than the current mess created by E_STRICT ... we wither
have to spend days reworking the code to respect E_STRICT ... or we
switch it
On 16 Jul 2014, at 23:45, Lester Caine les...@lsces.co.uk wrote:
On 16/07/14 23:12, Andrea Faulds wrote:
As I’ve explained earlier, letting them choose to make this fatal would be a
horrible, horrible idea.
This is no worse than the current mess created by E_STRICT ... we wither
have to
Hi!
The problem with making this RFC do the lossy thing is it then
removes one key advantage of it: that this RFC provides a measure of
strictness. Without that, we have no real compromise proposal, and we
might as well introduce a second set of “strict” type hints. The
whole point of the
On 16/07/2014 23:12, Andrea Faulds wrote:
Of course, we could just make it a glorified E_NOTICE, but then what’s the
point? E_NOTICE already exists.
I just realised something that's made me really confused about this
whole debate: internal functions already emit E_NOTICE for *exactly* the
Hi!
E_CAST is problematic. Having something we encourage some people to
make an error and some people not to means that in some cases your
library works fine and rosy in other people’s environments and
sometimes it crashes your app. This is *not good*. We must not
encourage people to make
On 17 Jul 2014, at 00:12, Stas Malyshev smalys...@sugarcrm.com wrote:
I think if the compromise is having multiple set of rules for implicit
casts then this compromise is not worth it. If you answer to the
question of what happens if I use a string in boolean context with
well, it depends,
On 17 Jul 2014, at 00:18, Rowan Collins rowan.coll...@gmail.com wrote:
Now, I have no idea how ZPP actually works, and get lost in a maze of macros
whenever I try to look at it, but evidently it has logic to distinguish, at
least for string-int, three cases:
1) safe / lossless / well
On 17 Jul 2014, at 00:23, Stas Malyshev smalys...@sugarcrm.com wrote:
I think this is not correct. It can be OK in one context and error in
another. I.e., if you say let's ask users how many gizmos they want
and the user gives 1 (note the space) and we tell them we don't know
what this even
On 17/07/2014 00:35, Andrea Faulds wrote:
zpp’s casts are (one form of) implicit cast. We actually do multiple different
kinds of implicit casts in different places with different results; “0xa” is
variously an integer and not an integer, depending on context, because nobody
seems to have
On 16/07/14 23:47, Andrea Faulds wrote:
This is no worse than the current mess created by E_STRICT ... we wither
have to spend days reworking the code to respect E_STRICT ... or we
switch it off. For legacy systems it simply HAS to be switched off and
on the whole the code works.
You know,
Hi!
There are really only two levels of error IMO, those that are log
file messages (silenced or no), and those that actually stop the
script unless handled. I worry about making E_CAST the former but
allowing people to make it the latter, because then people would and
suddenly code relying
On Mon, 14 Jul 2014, Stas Malyshev wrote:
In general, I am not in favour of casting typehints, as it would be
a different behaviour from the hard-check typehints that we already
have for classes and arrays.
It already is. All internal functions behave this way.
But casting typehints
On Mon, 14 Jul 2014, Rowan Collins wrote:
Derick Rethans wrote (on 14/07/2014):
A compromise by adding more inconsistencies.
The only way of not introducing some inconsistencies (or, to put it another
way, new features) is to use strict type hints, which perform no casting, and
error on
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, July 15, 2014 2:00 AM
To: Andrea Faulds; Chris Wright
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Hi!
I suggested on IRC that empty strings, TRUE
Message-
From: Jocelyn Fournier [mailto:jocelyn.fourn...@gmail.com]
Sent: 14 July 2014 14:30
To: n...@devilix.net
Cc: internals@lists.php.net; indey...@gmail.com; Andrea Faulds
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-
opening)
Hi,
Le 14/07/2014 15:19, Andrey
On Mon, Jul 14, 2014 at 7:19 PM, Kristopher kristopherwil...@gmail.com
wrote:
On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams a...@phcomp.co.uk wrote:
On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
On 14 Jul 2014, at 18:01, Alain Williams a...@phcomp.co.uk wrote:
On Tue, Jul 15, 2014 at 2:19 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 14, 2014 at 7:19 PM, Kristopher kristopherwil...@gmail.com
wrote:
On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams a...@phcomp.co.uk
wrote:
On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
On Tue, Jul 15, 2014 at 02:19:46PM +0200, Ferenc Kovacs wrote:
But php doesn't care, because one of it's distinguished features is that it
can coerce between scalar types.
Yes: and you will still be able to do that. No one will take that away, so
continue to use that where it is appropriate.
On 15 Jul 2014, at 13:50, Alain Williams a...@phcomp.co.uk wrote:
It will blow up with a fat E_RECOVERABLE_ERROR.
But this won't hold back the library authors from using it, which means
that the consumers of those libs has to start coding defensively, and make
sure that the variable holding
On Tue, Jul 15, 2014 at 2:50 PM, Alain Williams a...@phcomp.co.uk wrote:
On Tue, Jul 15, 2014 at 02:19:46PM +0200, Ferenc Kovacs wrote:
But php doesn't care, because one of it's distinguished features is that
it
can coerce between scalar types.
Yes: and you will still be able to do that.
On 15 Jul 2014, at 14:18, Ferenc Kovacs tyr...@gmail.com wrote:
you can't optionally introduce strict typing to php, as the two of them
can't co-exists.
nobody forces you to not use a language with strict typing if you want
that, but I don't think that it would worth changing the php type
On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:
On 15 Jul 2014, at 14:18, Ferenc Kovacs tyr...@gmail.com wrote:
you can't optionally introduce strict typing to php, as the two of them
can't co-exists.
nobody forces you to not use a language with strict typing if you
Ferenc Kovacs wrote (on 15/07/2014):
On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:
as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner) is a must.
Isn’t a must, surely? (I assume that was a typo)
I wasn't talking
On Tue, Jul 15, 2014 at 4:09 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Ferenc Kovacs wrote (on 15/07/2014):
On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:
as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner)
Ferenc Kovacs wrote (on 15/07/2014):
sorry, not a native speaker.
No problem, I think the intention was clear enough, and certainly meant
no criticism. :)
so you are saying that nobody argues that $someGenericStatement is
not proper grammar?
in my case the $someGenericStatement was that
Stas Malyshev wrote (on 14/07/2014):
But I'm not sure why you need this. You accept that if(foo)
works. Then why function foo(bool $x) { if($x) { ... should work
differently?
The answer - which is definitely a matter of opinion - is that allowing
any string reduces the usefulness of the type
On 15 Jul 2014, at 15:28, Rowan Collins rowan.coll...@gmail.com wrote:
Stas Malyshev wrote (on 14/07/2014):
But I'm not sure why you need this. You accept that if(foo)
works. Then why function foo(bool $x) { if($x) { ... should work
differently?
The answer - which is definitely a matter
On Mon, Jul 14, 2014 at 11:16 PM, Park Framework
park.framew...@gmail.com wrote:
Maybe we should make two different syntax?
fun(int $num, array $list) - for strict type compliance
fun((int) $num, (array) $list) - converted to type
It will be very obvious, and without magic.
Hi!
On the other hand, this RFC proposes a set of type hint casts which
have stricter rules than an explicit cast, and also somewhat stricter
than zend_parse_parameters, meaning that people can safely do
$_GET[‘thing’] and it’ll work, but if a nonsensical value is passed
in, the program will
Hi!
The answer - which is definitely a matter of opinion - is that allowing
any string reduces the usefulness of the type hint.
IMO, having consistent rules is much more, orders of magnitude more
important than serving any particular use case. We will always have use
cases in which any
1 - 100 of 246 matches
Mail list logo
