On 15 Jul 2014, at 18:24, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Stas Malyshev wrote (on 15/07/2014): >> IMO, having consistent rules is much more, orders of magnitude more >> important than serving any particular use case > > We are adding a new feature to a language which is already inconsistent. We > can only make it consistent with one part of the language by making it > inconsistent with another. > > If we take consistency as such a priority that we create a feature that is > not actually useful, we will have wasted our effort, and made the language > worse, not better. Saying "who cares if its useful, as long as it matches > some other part of the language" is a very poor argument IMO. > > That's an extreme, and I'm not saying anyone is saying precisely that, but I > am getting rather weary of the back-and-forth over what is "consistent", > rather than thinking about what we want to achieve, and what is the best way > to achieve that. I’d argue it’s better to do the right thing here, which is easier, and then do the right thing in the other place later, which is harder, than it is to do the wrong thing now because the other place also does the wrong thing. Having saner implicit casting for scalar type hints will be easier than changing the behaviour of zend_parse_parameters. >> What you want is strict typing then. > > No, I want to introduce the notion of a "lossless cast", allowing things like > (int)'123' to be valid. This distinction has been explained many times. > >> And if() working the same way - >> after all, if function can be unaware of the flag, if() is definitely >> unaware of it. > > Not necessarily. An if() statement is clearly and unambiguously working with > boolean values. Anyone looking at if( $foo & BIT_FLAG ) can know, based on > basic knowledge of the language, that an implicit cast is taking place. > > Someone looking at my_super_function( $foo & BIT_FLAG ) cannot know whether > that parameter is being interpreted as a boolean or is actually being > measured against that same BIT_FLAG (or some other integer operation) without > consulting the source code (or, at least, trusting the documentation). > >> I am not among them. If you want >> to enforce code style, we already have tools for that, but I don't think >> this particular one should be in the language. > > The logical conclusion from that is not to have type hints at all. So far, > that is in fact the only consensus the PHP community has ever reached - not > to have scalar type hints. (I don't mean that you necessarily hold that > position, but it is the logical conclusion of that particular line of > reasoning.) > > Regards, > Rowan Collins > -- > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > I, myself, generally agree with all this, though I’m not sure quite whether Anthony does at the moment. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
