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 (int, float,
Hi,
Would it possible to control the implicit casting through a PHP variable
? (or perhaps modify E_STRICT to display a warning if this kind of
implicit cast is done ?)
I mean specifying explicitly a type is often useful to make sure the
proper type is passed to the function, and there's no
On 13 Jul 2014, at 13:50, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
Would it possible to control the implicit casting through a PHP variable ?
(or perhaps modify E_STRICT to display a warning if this kind of implicit
cast is done ?)
No. I mean, yes, it’s possible, but allowing the
Hi,
Le 13/07/2014 14:56, Andrea Faulds a écrit :
On 13 Jul 2014, at 13:50, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
Would it possible to control the implicit casting through a PHP variable ? (or
perhaps modify E_STRICT to display a warning if this kind of implicit cast is
done ?)
On 13 Jul 2014, at 14:13, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
Actually displaying a warning in E_STRICT but still doing the implicit cast
would not change the function signature.
Sure. What I meant was more that we’re changing expectations based on
php.ini/variable/etc., and
On Sun, Jul 13, 2014 at 02:35:43PM +0300, Zeev Suraski wrote:
Type juggling is an *inherent* feature of PHP. Paraphrasing what Rasmus
said several years ago(*), 'if you implement this [strong typing], please
don't call it PHP'.
Again, luckily, what Andrea proposes isn't strong typing. It
Le 13/07/2014 15:17, Andrea Faulds a écrit :
On 13 Jul 2014, at 14:13, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
Actually displaying a warning in E_STRICT but still doing the implicit cast
would not change the function signature.
Sure. What I meant was more that we’re changing
On 13 Jul 2014, at 14:54, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
Ok, in this case I would suggest always displaying a warning in E_STRICT
since it's the whole purpose of the strict mode :)
Isn’t E_STRICT more for compile-time stuff? I’d think E_NOTICE would be the
appropriate
On 13 Jul 2014, at 13:09, Nikita Popov nikita@gmail.com wrote:
I haven't yet closely reviewed the details of what is and isn't allowed,
but one things I would strongly recommend against is introducing any
accept but throw a notice cases. Either a value is allowed or it isn't.
12foo to an
Which of the two below is clearer:
function CanDrive($age)
{
if( !is_numeric($age))
throw new Error(\$age is not integer (CanDrive()));
return $age = 17;
}
function CanDrive(int $age)
{
return $age = 17;
}
I think we're on the
Le 13/07/2014 15:58, Andrea Faulds a écrit :
On 13 Jul 2014, at 14:54, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
Ok, in this case I would suggest always displaying a warning in E_STRICT since
it's the whole purpose of the strict mode :)
Isn’t E_STRICT more for compile-time stuff?
I haven't yet closely reviewed the details of what is and isn't allowed,
but one
things I would strongly recommend against is introducing any accept but
throw a notice cases. Either a value is allowed or it isn't.
12foo to an int/float argument should throw a recoverable fatal error,
like
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, July 13, 2014 5:21 PM
To: Nikita Popov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 13 Jul 2014, at 13:09, Nikita Popov nikita@gmail.com wrote:
I haven't yet
On 13 Jul 2014, at 15:31, Zeev Suraski z...@zend.com wrote:
I think this is a big step in the wrong direction to one of the most
common auto-conversion use cases out there (HTTP input variables). See my
note to Nikita...
This RFC is a huge deal, I suggest we let more people voice their
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, July 13, 2014 5:34 PM
To: Zeev Suraski
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 13 Jul 2014, at 15:31, Zeev Suraski z...@zend.com wrote
On 13 Jul 2014, at 15:41, Zeev Suraski z...@zend.com wrote:
I don't think it's a common intentional case, but when writing code
defensively - you need to be prepared for whatever someone might through
at you... Say I have a form that accepts 'age', and I expect users to
type in their age.
Le 13/07/2014 16:41, Zeev Suraski a écrit :
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, July 13, 2014 5:34 PM
To: Zeev Suraski
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 13 Jul 2014, at 15
First of all thanks for this proposal. In general I’m hugely in favour of this
approach.
One thing however seems like a rather bad idea, and that is exposing the type
of resource in this way. Resources are not compatible between each other,
making such a hint not very useable. If people start
From my point of view, if the type annotations are doing implicit cast
(with or
without E_NOTICE/E_STRICT warning), they should behave exactly the same
than an explicit cast. If it behaves differently, I'll be really difficult
for a
developer to guess what will be the PHP behaviour with
On 13 Jul 2014, at 15:59, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
From my point of view, if the type annotations are doing implicit cast (with
or without E_NOTICE/E_STRICT warning), they should behave exactly the same
than an explicit cast. If it behaves differently, I'll be
On 13 Jul 2014, at 16:00, Rouven Weßling m...@rouvenwessling.de wrote:
First of all thanks for this proposal. In general I’m hugely in favour of
this approach.
One thing however seems like a rather bad idea, and that is exposing the type
of resource in this way. Resources are not
On 13/07/2014 15:41, Zeev Suraski wrote:
In other words, if someone types in '12a'
(by mistake or intentionally), I think it's a very sane behavior to just
treat it as 12, as opposed to forcing me (the developer) to write error
handling code with a try/catch block, and a fairly hairy try/catch
Le 13/07/2014 17:01, Andrea Faulds a écrit :
On 13 Jul 2014, at 15:59, Jocelyn Fournier jocelyn.fourn...@gmail.com wrote:
From my point of view, if the type annotations are doing implicit cast (with
or without E_NOTICE/E_STRICT warning), they should behave exactly the same than
an
On 13/07/2014 15:59, Jocelyn Fournier wrote:
From my point of view, if the type annotations are doing implicit cast
(with or without E_NOTICE/E_STRICT warning), they should behave
exactly the same than an explicit cast. If it behaves differently,
I'll be really difficult for a developer to
On 13 Jul 2014, at 16:01, Zeev Suraski z...@zend.com wrote:
From my point of view, if the type annotations are doing implicit cast
(with or
without E_NOTICE/E_STRICT warning), they should behave exactly the same
than an explicit cast. If it behaves differently, I'll be really difficult
for
On 13 Jul 2014, at 17:05, Andrea Faulds a...@ajf.me wrote:
On 13 Jul 2014, at 16:00, Rouven Weßling m...@rouvenwessling.de wrote:
One thing however seems like a rather bad idea, and that is exposing the
type of resource in this way. Resources are not compatible between each
other, making
On 13 Jul, 2014, at 11:17 pm, Rowan Collins rowan.coll...@gmail.com wrote:
On 13/07/2014 15:59, Jocelyn Fournier wrote:
From my point of view, if the type annotations are doing implicit cast (with
or without E_NOTICE/E_STRICT warning), they should behave exactly the same
than an explicit
Le 13/07/2014 17:17, Rowan Collins a écrit :
On 13/07/2014 15:59, Jocelyn Fournier wrote:
From my point of view, if the type annotations are doing implicit cast
(with or without E_NOTICE/E_STRICT warning), they should behave
exactly the same than an explicit cast. If it behaves differently,
On 13/07/2014 06:22, Stas Malyshev wrote:
I have one request: could we please stop calling it hinting?
I've always thought the current type hinting should be called type
assertion, since passing the wrong data type is detected only at
runtime, and causes an error in much the same way as if
On 13 Jul 2014, at 16:28, Rouven Weßling m...@rouvenwessling.de wrote:
On 13 Jul 2014, at 17:05, Andrea Faulds a...@ajf.me wrote:
On 13 Jul 2014, at 16:00, Rouven Weßling m...@rouvenwessling.de wrote:
One thing however seems like a rather bad idea, and that is exposing the
type of
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, July 13, 2014 6:19 PM
To: Zeev Suraski
Cc: Jocelyn Fournier; PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
1. Casting type hints
2. Strict type hints
3. Scalar type
On 13/07/2014 16:35, Jocelyn Fournier wrote:
That seems both inconsistent and less useful than a hybrid juggling +
validation approach.
Than means you find currently inconsistant than
$foo = (int) 'abc';
works but not
$bar = (object) 'abc';
? :)
Well, the ability to cast to an object at
On 13 Jul 2014, at 16:51, Rowan Collins rowan.coll...@gmail.com wrote:
Well, the ability to cast to an object at all is pretty wacky, since PHP has
no standard base class for objects, nor any mechanism to cast to or from
specific classes, etc.
Somewhat off-topic, but maybe we should make
Le 13/07/2014 17:51, Rowan Collins a écrit :
On 13/07/2014 16:35, Jocelyn Fournier wrote:
That seems both inconsistent and less useful than a hybrid juggling +
validation approach.
Than means you find currently inconsistant than
$foo = (int) 'abc';
works but not
$bar = (object) 'abc';
?
On 13/07/2014 16:45, Zeev Suraski wrote:
Even reading Nikita's piece, he's saying he dislikes that option for
'obvious reasons', but I see nothing obviously wrong with this approach.
[...] Unlike what's suggested in that piece, it's
not equivalent at all to docblocks, as it is in fact enforced,
On 13/07/2014 17:09, Jocelyn Fournier wrote:
If type hint is doing exactly the same than explicit cast, it should
not fail on wants_array('abc'), but give a warning about the implicit
cast conversion.
Agreed, but that's a very big if, and is not what this RFC is
proposing at all. Nor could
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com]
Sent: Sunday, July 13, 2014 7:09 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 13/07/2014 16:45, Zeev Suraski wrote:
Even reading Nikita's piece
On 13/07/2014 16:56, Andrea Faulds wrote:
Somewhat off-topic, but maybe we should make StdClass be the actual base class?
I mean, it’s already used as a generic object, and you could then put StdClass
as a type hint if you’re using an object as a key/value store but want to allow
Le 13/07/2014 18:15, Rowan Collins a écrit :
On 13/07/2014 17:09, Jocelyn Fournier wrote:
If type hint is doing exactly the same than explicit cast, it should
not fail on wants_array('abc'), but give a warning about the implicit
cast conversion.
Agreed, but that's a very big if, and is not
On 13 Jul 2014, at 17:29, Rowan Collins rowan.coll...@gmail.com wrote:
It's an interesting thought, but we currently have the object keyword for
that particular use case. In some languages, having a base object is useful
because functionality can be defined there, but PHP provides no way of
On 13/07/2014 17:28, Zeev Suraski wrote:
BTW, auto-converting type hints were
proposed by Lukas and me back in 2010, even though I see them attributed to
Anthony in 2012 :)
Aha, seems like a case of convergent thinking, with the exception that
Anthony proposed using distinct syntax to
On 13/07/2014 17:36, Andrea Faulds wrote:
On 13 Jul 2014, at 17:29, Rowan Collins rowan.coll...@gmail.com wrote:
It's an interesting thought, but we currently have the object keyword for that
particular use case. In some languages, having a base object is useful because
functionality can be
On 07/13/2014 11:28 AM, Zeev Suraski wrote:
Again, option #1 as I see it (and is mostly described in the 2010 RFC
https://wiki.php.net/rfc/typecheckingstrictandweak) - it's identical in
terms of rules to those of PHP's casting, but with warnings emitted for lost
data and 'bogus' conversions. If
On 13 Jul 2014, at 18:56, Larry Garfield la...@garfieldtech.com wrote:
We can discuss when the E_* should be emitted separately from what the cast
result is.
Is there any actual controversy over what the *result* of casts should be. This
RFC just has the normal casting result. Is anyone
On 13/07/2014 19:21, Andrea Faulds wrote:
On 13 Jul 2014, at 18:56, Larry Garfield la...@garfieldtech.com wrote:
We can discuss when the E_* should be emitted separately from what the cast
result is.
Is there any actual controversy over what the *result* of casts should be. This
RFC just
Hi!
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 (int,
float, bool, string and resource) with casting, with behaviour nearly
the same as
201 - 246 of 246 matches
Mail list logo
