Hmm that's a fascinating idea! So, and please correct me if I'm wrong, you're saying that it might be a better approach to determine strict vs. dynamic typing on a per file or function basis instead of on a per stack basis? In other words, blah.php could contain two functions, one using strict typing and the other using traditional dynamic typing?
Theoretically, I think that approach could work. Perhaps we'd have it specified in the function declaration itself; i.e. "function whatever( $text, $number )" would be a traditional, dynamically-typed PHP function, whereas "strict function whatever( string $text, int $number )" would use strict typing. The obvious question then would be, what if dynamic function A makes a call to dynamic function B, passing to it a dynamically-typed variable? There are three viable approaches that come to mind: This count not be allowed; this could be allowed but only if the variables being passed to function B are cast first (i.e. B( (string) $text, (int) $number );); or, this could be allowed without casting, in which case PHP would attempt to pass the variable and then throw an exception if it cannot be parsed as the required type. Personally, my vote would be for Option 2. I know this would be potentially confusing to people who are used to the existing language structure, but it's also worth noting that PHP has already changed quite a bit over the years and we've all managed to adapt. I'm thinking this would be perfect for PHP 6, since it would not be at all unreasonable to assume that there would be significant language changes that might require a slight learning curve at first, just as PHP 4 and 5 did. This is perhaps the most common complaint I hear about PHP. There are many programmers out there who think we're out of our minds (or just plain lazy) for not acting on this. I'm not one of them, mind you, but I can certainly see why they'd think that looking from the outside. I think it would be really awesome if we decided to finally tackle this head-on, despite the obvious discomfort that it would bring in the short-term; though I think much of that could be mitigated if we simply targetted this for PHP 6. --Kris 2012/2/23 Ángel González <keis...@gmail.com> > On 23/02/12 23:49, Kris Craig wrote: > > Yeah I agree, that was one of the things I listed under > > "disadvantages" lol. > > > > I guess my question is: Does this constitute a prohibitive problem, > > or is it something that we can stomach? > > > > I mean, if you think about it, that's really what we're talking about > > anyway, right? After all, when you're writing any application, you're > > either going to be writing it with strict typing or you're going to be > > writing it with dynamic typing. The only difference here is that > > coders with either preference will both find PHP accommodating to > > their style. > > > > > > Similarly, a somewhat weaker argument could be made that, in PHP 5, > > you're either coding for procedural design or for OO design > > (technically you could do both, but I wouldn't wanna touch that > > codebase with a ten foot poll lol). The only difference here is that > > there would be a config setting to tell the interpreter which is which. > > > > --Kris > I think you would get developers coding for strict, and hostings set to > weak. Makes more sense to have it as a per file / per function > attribute, so the author can choose if they want the values passed to it > to be coerced or act as if they were doing a manual check and throwing > an exception. > >
