Hi,
I'm with Stas here.
First let me say that I would like to see type hinting for scalars in
PHP. As a userland developer it would help me to write clean and more
robust code. But I think this proposal is only a workaround to get a
round the main problem. It's a try to push similar functionality into
PHP without breaking BC. I think it's the wrong way.
Anthony, You addressed one of the main issues in your last post.
Again, I personally see casting data-loss a bigger issue than just
parameter hinting, which should get its own RFC to clean up. That's
why I didn't include it here. On purpose...
Why not try to change this first?
I know there are more issues to solve. But I think only solving issue
piece by piece, regardless if BC breaks, brings a robust and clean
implementation of this feature. Not immediately, maybe in the next major
version.
Just my 2 cents.
Christian
Am 07.03.2012 08:31, schrieb Stas Malyshev:
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and
rather confusing, I really wouldn't like to have such syntax in PHP.
Also "(int) $foo = “1” will generate an E_COMPILE_ERROR" makes no
sense to me.
Also, this line:
function test((int) $intParam, (string) $strParam = "foo", (array)
$array) {}
is not proper PHP code - it contains optional parameter and then
parameter with no default.
And can we please stop using word "hinting"?
We can call it type conversion, typecasting, type coercion, etc.
http://en.wikipedia.org/wiki/Type_conversion
But I don't see how there's any hinting involved.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
