> > 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. >
Yes, exactly. I was only talking about this specific aspect. Otherwise, it is a fine and welcome proposal. I would love to have type-checking as long as it does not close the door to type-juggling some time in the future. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 Adam Jon Richardson <adamj...@gmail.com> > 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 >
