Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc...@php.net a
écrit :
This is definitely not the same case as generating a notice on array to
string (and why did you generate a notice instead of E_DEPRECATE, we would
be rid of this crap now).
I haven't decided that without discussing
Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc...@php.net a
écrit :
Why can't strictness follow that path?
Because strictness is not the overall objective the PHP language is aiming
to.
I cannot agree more with that.
If it was the case, your mechanism would be fine, but
as so important.
Regards
François
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
Envoyé : jeudi 19 février 2015 11:07
À : franc...@php.net; Sara Golemon
Cc : PHP internals
Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc
Le Wed Feb 18 2015 at 19:10:08, François Laupretre franc...@php.net a
écrit :
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
The biggest advantage, IMHO, is that you get the exact same result
whether
you do:
foo((int) $value);
or:
foo($value);
... whatever
2015-02-19 12:26 GMT+01:00 François Laupretre franc...@php.net:
Hi Patrick,
I know you didn’t decide it alone, but the right solution, IMO, would have
been to E_DEPRECATE nonsense conversions. That’s what we are currently doing
for ZPP conversions
[mailto:patrickalla...@php.net]
Envoyé : jeudi 19 février 2015 13:46
À : franc...@php.net; Sara Golemon; PHP internals
Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
Le Wed Feb 18 2015 at 19:10:08, François Laupretre franc...@php.net a écrit :
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
The biggest
Hi,
On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: Wednesday, February 18, 2015 3:06 AM
To: Rasmus Lerdorf
Cc: Sara Golemon; PHP internals
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
On 17/02/15 23:03, Sara Golemon wrote:
1) Introduce scalar types for primitives: bool, int, float, string,
resource, object (we already have array)
1a) Introduce meta-types as pre-defined unions (we can add custom
unions in a later rfc). A possible list may be as follows (again, we
can
Nikita Popov wrote on 18/02/2015 00:35:
I don't like the way this is heading with regards to internal functions.
Apart from better inter-compatibility, the primary appeal of Andrea's
proposal was that we have the option to make not only userland function
calls strict, but internal ones as well.
Michael Wallner wrote on 18/02/2015 11:19:
On 17/02/15 23:03, Sara Golemon wrote:
1) Introduce scalar types for primitives: bool, int, float, string,
resource, object (we already have array)
1a) Introduce meta-types as pre-defined unions (we can add custom
unions in a later rfc). A possible
On 18/02/15 09:14, Andrey Andreev wrote:
That is especially bad when such identifiers are in fact generated as
integers first so that they are incremental, but the
program/database/business logic requires them to be fixed-length
strings and/or in hexadecimal format. In such cases, even
On 18/02/15 12:31, Rowan Collins wrote:
Michael Wallner wrote on 18/02/2015 11:19:
On 17/02/15 23:03, Sara Golemon wrote:
1) Introduce scalar types for primitives: bool, int, float, string,
resource, object (we already have array)
1a) Introduce meta-types as pre-defined unions (we can add
Hi,
On Wed, Feb 18, 2015 at 11:54 AM, Lester Caine les...@lsces.co.uk wrote:
On 18/02/15 09:14, Andrey Andreev wrote:
That is especially bad when such identifiers are in fact generated as
integers first so that they are incremental, but the
program/database/business logic requires them to be
On 18 בפבר׳ 2015, at 19:50, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/18/2015 08:51 AM, François Laupretre wrote:
De : Pádraic Brady [mailto:padraic.br...@gmail.com]
Careful, it helps not to call folk radicals if you intend to pursue
a compromise with them ;).
Sorry, english is
On Wed, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT patrickalla...@php.net wrote:
Regarding 2) and 3):
An option might be to implement weak mode only and configure the coercion
rules reporting in a similar way than with the error_reporting
configuration entry.
ini_set(coercion_reporting,
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
ini_set(coercion_reporting, COERCION_ERROR); // Fail in case of
potentially bad coercion
foo(7);
// int(7)
foo(7);
// int(7)
foo(7 dogs);
// Catchable fatal error: Unsafe coercion transforming 7 dogs to 7.
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
What if we defined the types as names in the \PHP namespace, but defined
a slightly different algorithm for resolving typehints vs other uses:
function foo(\PHP\types\numeric $a) // unambiguous but unwieldy
function
De : Zeev Suraski [mailto:z...@zend.com]
That means that 42 can coerce into int, and 42.2 can coerce into float,
and int can coerce into float - but not vice versa.
I was wondering : should we systematically reject float to int, or should we
accept it when range fits and fractional part is
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
The biggest advantage, IMHO, is that you get the exact same result whether
you do:
foo((int) $value);
or:
foo($value);
... whatever the mode you are in.
Wrong. Parameter parsing rules are much more restrictive than
On 02/18/2015 08:51 AM, François Laupretre wrote:
De : Pádraic Brady [mailto:padraic.br...@gmail.com]
Careful, it helps not to call folk radicals if you intend to pursue
a compromise with them ;).
Sorry, english is not my native language, and 'radical' may be offensive.
I was just
François Laupretre wrote on 18/02/2015 18:05:
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
What if we defined the types as names in the \PHP namespace, but defined
a slightly different algorithm for resolving typehints vs other uses:
function foo(\PHP\types\numeric $a) // unambiguous
On 18/02/15 17:55, Zeev Suraski wrote:
We can limit ourselves to values below that limit. If you deal with values
above it, be explicit about casting.
This is exactly my problem ...
Databases are using 64bit primary keys more and more, and having to
worry about going over some limit is the
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
They'd use whatever (non-reserved) namespace the implementer wanted.
e.g.
namespace Symfony\Component\TypeChecking;
basicType nonNegativeInt extends PHP\types\int {
public function isValid(int $value) {
return $value =
Le Wed Feb 18 2015 at 18:35:02, François Laupretre franc...@php.net a
écrit :
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
ini_set(coercion_reporting, COERCION_ERROR); // Fail in case of
potentially bad coercion
foo(7);
// int(7)
foo(7);
// int(7)
Le Wed Feb 18 2015 at 19:10:54, Sara Golemon poll...@php.net a écrit :
On Wed, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT patrickalla...@php.net
wrote:
Regarding 2) and 3):
An option might be to implement weak mode only and configure the
coercion
rules reporting in a similar way than with
De : Zeev Suraski [mailto:z...@zend.com]
If we do implement the single-mode, stricter-than-pure-weak and
weaker-than-pure-strict ruleset, we could introduce a new set of conversion
functions, along the lines of safe_int(), that would follow the same rules
as the corresponding type hints
De : Pádraic Brady [mailto:padraic.br...@gmail.com]
However, “123” is exceptional. It’s redefining an integer as “ an
integer or a string comprised wholly of digits without leading zeroes,
with an optional leading hyphen, and representing an integer up to
PHP_INT_MAX”
Add leading zeros, and
Hi,
Octal is something that can often be miss converted since it IS the same
as an integer with only a '0' in front in PHP. But that is not something
that can be fixed with the current proposals?
What do you propose ? Considering leading zero as octal indicator is not an
option, IMO. If you
Leigh wrote on 18/02/2015 13:10:
3b) Internal impact: Again, behavior remains unchanged unless the
ZEND_ARG_INFO struct has been modified to add proper typehints. If
typehints have been added, then the more aggressive coersion rules
apply during typehint validation.
This leaves us in a state
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and on
the
very first if it was a strict hint:
for ($i = 0; $i 11; $i++)
{
Hi,
On Wed, Feb 18, 2015 at 2:27 PM, François Laupretre franc...@php.net wrote:
Hi Andrey,
De : Andrey Andreev [mailto:n...@devilix.net]
I too am curious about the potential issue with 123 to 123
specifically, although it could be seen as a subset of another problem
that is solved with
On 18 February 2015 at 13:18, Rowan Collins rowan.coll...@gmail.com wrote:
This leaves us in a state where some functions will have defined types
with their aggressive coersion rules and some will not, and we can't
expect users to remember which set of functions have been updated or
not.
De : Robert Stoll [mailto:p...@tutteli.ch]
Strict mode is useful in the sense that it prevents unnecessary implicit
conversions (which are costly) and it improves readability.
Following an example:
function foo(string $x, int $y){
bar(1);
return strstr($x,hello, $y);
}
function
Leigh wrote on 18/02/2015 13:31:
On 18 February 2015 at 13:18, Rowan Collins rowan.coll...@gmail.com wrote:
This leaves us in a state where some functions will have defined types
with their aggressive coersion rules and some will not, and we can't
expect users to remember which set of functions
On 18 February 2015 at 14:40, Lester Caine les...@lsces.co.uk wrote:
But my favourite is still
'\143\141\164' == \143\141\164 which is false, but I doubt many would
know why?
Pretty sure one of the first things PHP devs learn is that single
quoted strings only accept \' and \\ as escape
On 18/02/15 12:33, François Laupretre wrote:
Octal is something that can often be miss converted since it IS the same
as an integer with only a '0' in front in PHP. But that is not something
that can be fixed with the current proposals?
What do you propose ? Considering leading zero as octal
Hi all,
On 18 February 2015 at 09:14, Andrey Andreev n...@devilix.net wrote:
Hi,
On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski z...@zend.com wrote:
I am wondering what the point is indeed with preventing 123 to 123. So
far, all the concrete use cases people brought up had to do with Apple
Michael Wallner wrote on 18/02/2015 11:39:
On 18/02/15 12:31, Rowan Collins wrote:
Michael Wallner wrote on 18/02/2015 11:19:
On 17/02/15 23:03, Sara Golemon wrote:
1) Introduce scalar types for primitives: bool, int, float, string,
resource, object (we already have array)
1a) Introduce
Hi Andrey,
De : Andrey Andreev [mailto:n...@devilix.net]
I too am curious about the potential issue with 123 to 123
specifically, although it could be seen as a subset of another problem
that is solved with strict hints - numeric-character string
identifiers being erroneously treated as
: Zeev Suraski [mailto:z...@zend.com]
Gesendet: Mittwoch, 18. Februar 2015 08:00
An: Nikita Popov; Rasmus Lerdorf
Cc: Sara Golemon; PHP internals
Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
I am wondering what the point is indeed with preventing 123 to 123.
So far, all the concrete
De : Andrey Andreev [mailto:n...@devilix.net]
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and
on the very first if it was a strict
Hi Nikita,
I don't like the way this is heading with regards to internal functions.
Apart from better inter-compatibility, the primary appeal of Andrea's
proposal was that we have the option to make not only userland function
calls strict, but internal ones as well. With these modifications
On 17 February 2015 at 22:03, Sara Golemon poll...@php.net wrote:
Based on conversations here and elsewhere on the internet, I'd like to
put forward a rough gameplan for scalar types which I hope addresses
most concerns. This is back-of-the-napkin and I'm not asking for a
committed yes/no,
Hi Zeev,
On Wed, Feb 18, 2015 at 2:31 PM, Zeev Suraski z...@zend.com wrote:
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and on
the
Hi François,
On Wed, Feb 18, 2015 at 3:02 PM, François Laupretre franc...@php.net wrote:
De : Andrey Andreev [mailto:n...@devilix.net]
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would
Hi Michael,
The case of null is a little special.
As a type hint, we need it for return and union types only.
Considering union types, they were clearly left out of scope for 7.0 and I
personally won't propose pre-defined union types before the general case for
unions is designed. Conversion
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
That's precisely the case for every existing user-defined function.
Switching to PHP 7 won't suddenly add type hints to every function in
every library and every existing bespoke code base, so there is no way
to avoid that thought process.
Hi Sara (and thanks for continuing the work!)
Le Tue Feb 17 2015 at 23:04:20, Sara Golemon poll...@php.net a écrit :
[...]
2) Define a way to enable strict mode (we'll be weak by default).
[...]
3) Tighten up coersion rules for weak mode. i.e. 10 dogs for an int
is a violation, but 10 is
On 18/02/15 14:59, Pádraic Brady wrote:
I wouldn't necessarily mind int-float - it's lossless assuming one way only.
Assuming int is not 64 bit ;)
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services -
De : Leigh [mailto:lei...@gmail.com]
Can we keep a 0) of reserve names for future use in-case of RFC
failure option.
Reserving names is only needed as long as we keep keywords sharing the same
naming space as classes. This is a mistake from the past and, as long as we
keep it, each new
2015-02-18 12:45 GMT+01:00 Rowan Collins rowan.coll...@gmail.com:
Michael Wallner wrote on 18/02/2015 11:39:
On 18/02/15 12:31, Rowan Collins wrote:
Michael Wallner wrote on 18/02/2015 11:19:
On 17/02/15 23:03, Sara Golemon wrote:
1) Introduce scalar types for primitives: bool, int,
On 18 February 2015 at 13:30, François Laupretre franc...@php.net wrote:
Actually, your example is partially invalid because strict-typing radicals
now propose to add a (int - float) exception to so-called strict mode (which
proves the approach is flawed, IMHO).
Careful, it helps not to
De : Lazare Inepologlou [mailto:linep...@gmail.com]
So, yes it would be nice null not to be included in scalars. Instead, we
could have a union type like scalar? = scalar|null
That's roughly the idea. However, IMO, the general mechanism for union types
needs to be defined before we start
On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/17/2015 04:35 PM, Nikita Popov wrote:
I don't buy into Rasmus arguments about internal functions. They concern
one particular edge case
François Laupretre wrote on 18/02/2015 15:47:
De : Leigh [mailto:lei...@gmail.com]
Can we keep a 0) of reserve names for future use in-case of RFC
failure option.
Reserving names is only needed as long as we keep keywords sharing the same
naming space as classes. This is a mistake from the
De : Pádraic Brady [mailto:padraic.br...@gmail.com]
Careful, it helps not to call folk radicals if you intend to pursue
a compromise with them ;).
Sorry, english is not my native language, and 'radical' may be offensive.
I was just looking for a word for people who consider providing two
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
My point is that it potentially imposes new warnings on foreign code.
Eureka :)
That's what happened when I introduced the Array to string conversion:
lot of people complained about it and many frameworks had to fix various
issues
On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov nikita@gmail.com wrote:
This is exactly what I fear will happen with an arginfo based approach. If
even fundamental aspects like the 123 vs 123 (or true vs 1) distinction
are suppressed for internal functions, this isn't a strict typing mode,
On 02/17/2015 04:35 PM, Nikita Popov wrote:
I don't buy into Rasmus arguments about internal functions. They concern
one particular edge case (int-float coercion) and I doubt they have much
relevance if applied to codebases with pervasive use of typehints (where
you can be reasonably sure of
On Tue, Feb 17, 2015 at 4:35 PM, Nikita Popov nikita@gmail.com wrote:
I don't like the way this is heading with regards to internal functions.
Apart from better inter-compatibility, the primary appeal of Andrea's
proposal was that we have the option to make not only userland function
calls
On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/17/2015 04:35 PM, Nikita Popov wrote:
I don't buy into Rasmus arguments about internal functions. They concern
one particular edge case (int-float coercion) and I doubt they have much
relevance if applied to
On Tue, Feb 17, 2015 at 11:03 PM, Sara Golemon poll...@php.net wrote:
Based on conversations here and elsewhere on the internet, I'd like to
put forward a rough gameplan for scalar types which I hope addresses
most concerns. This is back-of-the-napkin and I'm not asking for a
committed
On Wed, Feb 18, 2015 at 4:05 AM, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 02/17/2015 04:35 PM, Nikita Popov wrote:
I don't buy into Rasmus arguments about internal functions. They
concern
one particular edge
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: Wednesday, February 18, 2015 3:06 AM
To: Rasmus Lerdorf
Cc: Sara Golemon; PHP internals
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
The inability to implicitly cast 123 to int is pretty much the KEY
64 matches
Mail list logo
