Err typo correction: In my "what if" scenario, I meant to say, "what if dynamic function A makes a call to *static* function B".
--Kris 2012/2/23 Kris Craig <kris.cr...@gmail.com> > 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. >> >> >
