On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou <linep...@gmail.com>wrote:
> Of note, the scalar type hinting I've outlined does not automatically >> perform casts... > > > Thank you for your answer. Maybe, this exact fact is what I don't like > about your suggestion. Please read the following RFC, where Lukas Smith and > Zeev Suraski explain very well why strict type checking without > auto-casting is a not a great idea. Of course it is just an RFC, but I find > it quite correct. > https://wiki.php.net/rfc/typecheckingstrictandweak I believe we interpret that RFC differently. Those who wrote it can correct me if I'm in error. The RFC is a very interesting approach to providing some form of type hinting for scalar parameters in functions and methods. I liked the RFC, but I understand some of the concerns that come up when discussing something like it. First, I believe that when the RFC contrasts strict and weak typing, it would be fair to say this is what many others would describe as strong vs weak typing: http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing The RFC makes the case that strict typing is "is an alien concept to PHP", and that it "goes against PHP's type system", while pointing out other issues. The RFC makes it clear that trying to map strict typing onto PHP is problematic, and on this issue I tend to agree. The RFC then offers three options for weak type hinting. One main point I'd bring out for all of the options is that they all strengthen the typing (that is, while still a weak type system, it moves slightly towards the strong side of the continuum) beyond PHP's default type juggling rules because some type of error would be raised in the event of data loss. So, their proposal outlines weak forms of type hinting for scalars, and mine is similar but weaker, as there is no auto casting, there are no new errors raised for data loss, and all checks are against the generic scalar type (whether with or without the aliases.) This brings my proposal even closer to the fundamental typing characteristics of PHP, whilst protecting against the potential errors pointed out in my earlier examples. > > My concern is that if your suggestion is adopted (as it is, without > auto-casting) then an eventual introduction of auto-casting will be > impossible without breaking BC. > This is a potential concern if the aliases for scalar were included (bool, int, float, string), as Anthony mentioned, although merely implementing the first part of the proposal (scalar type hinting) wouldn't cause any trouble. However, the more a proposal moves away from PHP's current typing conventions, the less likely it is to be considered, let alone approved. I'm not confident a more aggressive proposal (e.g., auto-casting with checks for information loss) would be approved any time soon. PHP is one of the most practically oriented programming languages I'm aware of, and my practicalities just want to put forward ideas that improve some issues AND that might actually get done :) Again, thanks for the commentary, Lazare. Adam
