On Tue, Jul 15, 2014 at 11:05 PM, Andrea Faulds <a...@ajf.me> wrote: > > On 15 Jul 2014, at 21:02, Andrey Andreev <n...@devilix.net> wrote: > >> Unless you really force the camps to pick one by saying "you can't >> have Y if we've got X" (to which there's no technical limitation, so >> that's not true) > > No technical limitation, sure, but it would be really weird for PHP to go in > two completely opposite directions at the same time!
Depending on what we're talking about, it could be two directions or two very high-level features that wouldn't have room for more improvement, making them boundaries, not directions. By trying to be abstract in my previous writing, I guess I didn't clarify what I'm referring to by X and Y. Read below please. :) On Wed, Jul 16, 2014 at 11:31 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Andrey Andreev wrote (on 15/07/2014): > > >> I'm sorry, I know what you mean here and I'm not criticizing you >> specifically (in fact, I'm intentionally taking it ouf of context), >> but that's "PHP internals", not "PHP community". > > > Point taken, but there's plenty of overlap between the two; it's not like > everyone on this list is a 1337 hardcore C hacker who only writes PHP code > to test their latest cool patch to the Zend Engine. It would be interesting > to have this debate at a PHP conference or large user-group and see if it > came out the same way, but I've no particular reason to suppose it wouldn't. That is true to some extent, but the majority of regular participants in these discussions are the ones who write the C code. Also, the conclusion that I quoted is (I believe) based on previously rejected proposals for scalar type hints. Ultimately, only that same group of people can reject it, because they are the voters. >> Unless you really force the camps to pick one by saying "you can't >> have Y if we've got X" (to which there's no technical limitation, so >> that's not true) > > > That's fine, as long as you don't count the syntax as part of the feature. > Since everybody would like their preferred version to be written the same > way, then, yes, there's a very obvious technical limitation: given > > function foo(int $bar) > > there has to be a single interpretation. As soon as that interpretation is > chosen, it is chosen for all time, and there is no way we can make it mean > something else later. > > Now, one form of compromise is to use variants of the syntax, such as... > > function foo((int) $bar) > function foo(-int $bar) > function foo(+int $bar) > function foo(~int $bar) > function foo(int! $bar) > etc > > ...but we still have to decide which behaviour to implement first, and which > syntax to give it. Exactly my point. I had already expressed my support for using another syntax, because if the current one is used for type cast hints, then strict type hints would be practically impossible in the future. > There's also variants of some of the features that really wouldn't make > sense to pick two of: I don't think anyone wants a language which has "weak > cast", "strict cast", and "really strict cast" alongside each other. So we > can't just say "implement all the versions and let users choose", either. > > I appreciate the frustration of the debate going round in circles, I feel it > too. But without a benevolent dictator, we have to somehow reach a > compromise. Feel free to suggest your preferred compromise, as long as it's > not "just do the one I want and maybe other people can add theirs later with > an as-yet-unspecified syntax" (not that that is what you were asking for, > exactly, I've taken it to extremes to make a point). Of course, I am not suggesting to introduce 3 different kinds of casting rules. X vs Y in my case point was type cast hints vs strict type hints. I understand that this RFC is about type cast hints and that's fine with me. My problem with it is that every suggestion for a change in it is shot down via rhetorics built around the dogma that PHP is a weakly typed language or that we're talking about a different feature here, completely ignoring the concern that keeping it as is may prevent another useful feature from being implemented in the future. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
