[RFC - Discussion] Parameter Type Casting Hints

14 years ago by Anthony Ferrara — view source — reply

unread

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

14 years ago by Paul Dragoonis — view source — reply

unread

Can you make sure that only scalar or array casts can be done?

I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)

Paul.

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

14 years ago by Anthony Ferrara — view source — reply

unread

Can you make sure that only scalar or array casts can be done?

I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)

That's how it is implemented now. That'll generate a parse error...

14 years ago by Paul Dragoonis — view source — reply

unread

Good.

Can you make sure that only scalar or array casts can be done?

I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)

That's how it is implemented now. That'll generate a parse error...

14 years ago by Lazare Inepologlou — view source — reply

unread

I wouldn't want people to put class typehints in there such as

function foo( (SomeClass) $foo)

Why not? I would definitely like something like that, in the future. Here
is an example:

class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new DateTime;
$date->add( 'P3D' ); // string to DateInterval casting
$date->add( 3600 ); // int (seconds) to DateInterval casting

Personally, I find this to be much closer to free type-juggling PHP style
than the current implementation with type hints (
http://www.php.net/manual/en/datetime.add.php).

[ Actually, I would prefer even type hints to work like this. Check if the
passed argument if of the correct type and, if not, try to cast it. Failure
to do so will lead to the E_RECOVERABLE_ERROR as today. ]

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/4 Paul Dragoonis dragoonis@gmail.com

Can you make sure that only scalar or array casts can be done?

I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)

Paul.

On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

14 years ago by Paul Dragoonis — view source — reply

unread

Is (DateInterval) a valid cast currently in PHP ?

If not, then we're not looking to add new fancy casting options, just
give casting options on the simple existing ones.

Paul.

I wouldn't want people to put class typehints in there such as

function foo( (SomeClass) $foo)

Why not? I would definitely like something like that, in the future. Here is
an example:

class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new DateTime;
$date->add( 'P3D' ); // string to DateInterval casting
$date->add( 3600 ); // int (seconds) to DateInterval casting

Personally, I find this to be much closer to free type-juggling PHP style
than the current implementation with type hints
(http://www.php.net/manual/en/datetime.add.php).

[ Actually, I would prefer even type hints to work like this. Check if the
passed argument if of the correct type and, if not, try to cast it. Failure
to do so will lead to the E_RECOVERABLE_ERROR as today. ]

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/4 Paul Dragoonis dragoonis@gmail.com

Can you make sure that only scalar or array casts can be done?

I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)

Paul.

On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

14 years ago by Simon Schick — view source — reply

unread

Hi, Lazare

This is something not obvious, at least for me, and should be handled in
the function itself.

Here it would be better to update the function add() that you could also
pass mixed and it will try to generate a *DateInterval *out of that or
whatever.
But that's another RFC.

Type-juggling applies just to weak-types like string, int, float and
boolean. I don't like to have this for resource, array or class excepted
they are compatible to each other (like array and SplFixedArray,
SplObjectStorage, ArrayIterator, ...)
If you have to do something special to get the expected type (like creating
a new object) type-juggling would not be the good-way to go.

Bye
Simon

2012/3/4 Lazare Inepologlou linepogl@gmail.com

I wouldn't want people to put class typehints in there such as

function foo( (SomeClass) $foo)

Why not? I would definitely like something like that, in the future. Here
is an example:

class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new DateTime;
$date->add( 'P3D' ); // string to DateInterval casting
$date->add( 3600 ); // int (seconds) to DateInterval casting

Personally, I find this to be much closer to free type-juggling PHP style
than the current implementation with type hints (
http://www.php.net/manual/en/datetime.add.php).

[ Actually, I would prefer even type hints to work like this. Check if the
passed argument if of the correct type and, if not, try to cast it. Failure
to do so will lead to the E_RECOVERABLE_ERROR as today. ]

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/4 Paul Dragoonis dragoonis@gmail.com

Can you make sure that only scalar or array casts can be done?

I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)

Paul.

On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

14 years ago by Lazare Inepologlou — view source — reply

unread

Anthony, just a tiny detail in your RCF:

So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo

= “1” will generate an E_COMPILE_ERROR.

If null is going to be cast, (int)null is 0. So I don't think it should be
a valid default value.

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/4 Anthony Ferrara ircmaxell@gmail.com

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

14 years ago by Paul Dragoonis — view source — reply

unread

It would make sense that the default value you're setting matches the
zval.type of the casted value.

You always want it to be an int, if you're doing (int) so setting it
to a string or array would not make sense.

Paul.

Anthony, just a tiny detail in your RCF:

So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo

= “1” will generate an E_COMPILE_ERROR.

If null is going to be cast, (int)null is 0. So I don't think it should be
a valid default value.

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/4 Anthony Ferrara ircmaxell@gmail.com

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

14 years ago by Anthony Ferrara — view source — reply

unread

Anthony, just a tiny detail in your RCF:

So (int) $foo = null and (int) $foo = 1 are both supported, but (int)
$foo = “1” will generate an E_COMPILE_ERROR.

If null is going to be cast, (int)null is 0. So I don't think it should
be a valid default value.

Well, there were two reasons that I added null: first, for consistency with
the existing type hints. Second, and more importantly, to allow checking
if a parameter is specified. So without null, you couldn't tell the
difference between an explicit 0 and an implicit (not specified) 0. This
way, you can. I admit the use cases for that are rather slim, but a good
portion of internal functions behave this way (substr comes to mind)...

I think it is worth discussing further, as your point is indeed valid...

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/4 Anthony Ferrara ircmaxell@gmail.com

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

--

Anthony, just a tiny detail in your RCF:

So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo

= “1” will generate an E_COMPILE_ERROR.

If null is going to be cast, (int)null is 0. So I don't think it should be
a valid default value.

Lazare INEPOLOGLOU
Ingénieur Logiciel

2012/3/4 Anthony Ferrara ircmaxell@gmail.com

Hey all,

I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).

https://wiki.php.net/rfc/parameter_type_casting_hints

Please provide feedback here on the implementation and RFC topics.

Thanks,

Anthony

[RFC - Discussion] Parameter Type Casting Hints View as Markdown