On 14 Sep 2014, at 16:40, Andrey Andreev <n...@devilix.net> wrote: > ... and I responded to this in the next paragraph. Userland doesn't > case about internal differences, that's why they're called internal > and why people outside of php-internals have for so long been puzzled > why we only have array and object type hints.
"Internal functions” refers to functions from extensions. It has no relation to internal*s*, the mailing list. > That's exactly what I'm talking about ... we already have a syntax for > strict typing, (and I want to put an emphais on this) *regardless of > the reasons why, we do have strict type hints*. I don't understand why > everybody is pretending that PHP doesn't have that feature just > because we're talking about scalars here. Nobody’s arguing we don’t already have strict type hints. I’m arguing strict hints don’t make sense for scalars. Note that we document strict (array, object) parameter types and non-strict (scalar) parameter types in the same way in our documentation. > Speaking strictly from a userland perspective, using that same syntax > for something different will be inconsistent and will cause confusion. > That another syntax could be used for strict typing in the future is > just not a serious thing to say. Why is it "not a serious thing to say”? I don’t understand. > You can't say it's the worst of both worlds when you have both worlds > in their entirety. No, you can. Allowing both options can be “the worst of both worlds”. This is just a trivial matter of semantics, though. > And most importantly, they have always been two > separate worlds because they just don't make sense otherwise. Have they? We already mix strict and non-strict typing in PHP. Functions taking objects, internal or not, will error if you pass the wrong type of object. Internal functions taking scalars will not error and instead cast, at least most of the time. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php