On Sun, Sep 14, 2014 at 6:47 PM, Andrea Faulds <a...@ajf.me> wrote: > > 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.
I'm aware of that, hence why I said 'php-internals' to refer to the mailing list. Again, userland devs don't care about that - PHP is their language and they only care how we/they interact with it, not what happens under the hood. Imagine for a moment that you've never been involved in the development of PHP itself and you'll see how what I say makes a lot of sense. >> 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. And because you don't think it makes sense (and that might mean you don't think it _now_), you're ignoring it. That's also a reason why the documentation is done that way - nobody has thought of writing it differently, because they didn't have to. The docs can always be updated, but once the language changes, there's no going back. >> 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. Because it's obvious that you're not even thinking of that as a possibility. What would that syntax be? "function foo([int] $bar)" ? As I already said, we already have and use a syntax for strict typing. This RFC uses that same syntax for something different and that's wrong, hence why the RFC should be changed, not the other way around. >> 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. I'll ... just say that it's also the best of both worlds and agree to disagree, I think you got the idea. >> 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. I already noted multiple times that I'm talking as a userland developer and that no userland developer (generally speaking, of course) cares about internal functions. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
