Hi! > > I don't think you need boilerplate for every call. Either you create > what you're going to pass to said function call, or you type-hint it > properly on that method. The onus is on the creator of the variable, not > the consumer. > > Additionally, we could add other is_* functions for these agregate type > hints. is_iterable(), etc...
And pretty soon we'd have dozens of is* functions for types ranging from "valid IPv6 address" to "properly initialized object of one of the four types named below", driven by random use cases. I don't think it's a proper way to design a language type system. > How would downstream affect you? I would understand upstream, but I > don't get that point... Could you elaborate further? If you call some function, that calls some function, that calls some function that has strict type check, you need to ensure that that type check is satisfied, otherwise your code blows up in runtime and you'd have no way to correct for it. Since PHP does not have static type checking, the only way to ensure this does not happen is to catalogue all code paths that have such things happening and insert checks that ensure you pass the correct type. Of course, in practice nobody would do that - they'd just right the code assuming everything is fine and then when it does blow up they'd sit for days with a debugger trying to figure out why the damn variable is of the wrong type here in 1.5% of hard-to-reproduce cases. When we're talking about proper types such occasions would be rare enough, but once we start introducing use-case-driven pseudo-types, IMHO it will quickly become a mess. > It's a Recoverable error, so no, it doesn't have no choice but to blow > up the whole ap. You can install an error handler and recover from them. "recoverable" errors is another in the gallery of misnomers we have around this - it's not recoverable. How exactly you recover from it? If you handled it in the code, you could return or assume some default value, you could take different code path, etc. - but in centralized error handler pretty much only thing you can do is to display a nice error message and shut down the whole thing. > The point being that it pushes the call-time checks used by defensive > programming into the language instead of as requiring a lot of > copy-paste to validate arguments... Which I think is exactly wrong thing to do, because PHP does not have proper tools to handle it - if pushing it into the language means we promote "log and shut down" approach to handling any exceptional situation. For some cases, it may be appropriate, but I think we're taking it too far by creating ad-hoc type system based on it. > Well, that's an odd point, because almost all of the other dyanmic typed > languages (at least of the popular ones) are object oriented at core. So > this sort of type hinting can be done by `assert($obj instanceof Foo)`. It can be done in PHP too. However I don't think people actually do it. > With PHP, given the first-class primitives, this is not as straight > forward. I'm not saying that we shouldn't take cues from other > languages, but to implement or not based on what other languages do is a > bit odd, given that PHP is unique in a lot of ways from those other > languages... I still call you to think why such things aren't done, instead of refusing to consider it by just saying "PHP is unique, so we don't care what happens with the rest of the world". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
