On Wed, Aug 11, 2010 at 9:29 PM, Josh Davis <php...@gmail.com> wrote:
>
>
> If I'm using type checking as a sanity check then it doesn't work as
> soon as it accepts "1" for an int. The described "weak typehinting" is
> good if you're looking for a way to validate input. However, it does
> not work if you're trying to make sure that Stuff Is Going As
> Planned(tm). For example, consider a protected method
> getTheNextNTokens(int $n) which is part of some tokenizer or
> something. It is a protected method and you never write
> getTheNextNTokens("2") so if it ever receives something that is not an
> integer, it means that there's a subtle bug somewhere. In that case,
> "strict typehinting" buys you peace of mind.
>
>
HiThank you for the use case, we need more of them. However in this example, what kind of application wouldn't make this $n parameter configurable (ini file, XML file, user preference from a database etc.) at some point? Then you would be back to square one, meaning you would have to cast your database output so that your strict API accepts the natural evolution of your app. Or you would have to get rid of the strict check and replace it with a userland checking and validation chain (which you should do anyway), at which point you wouldn't need or want type checking but you would be glad to have type casting. In PHP, every single value potentially comes from a kind of stream (file, HTTP or otherwise), there is no such thing as a fully internal configurable value that I can think of. Or is there? If there is, why would it need type checking at all? Type checking or type casting won't save you much trouble since, as you said yourself, in both cases you need to properly validate any data before doing anything funny. However, with type checking you don't get any actual benefit that I can see, while with type casting you can do other things relying on the cast to properly format some of your data for you. If you have a validation chain, why do you need type checking? If you don't validate your data, type checking won't help. It would give a false sense of security, nothing more. In edge cases like you described, type checking leaves you with a broken app (fatal error / white page), while with type casting you'd have a kind of recoverable error that you could... recover from. In neither case your users care what happens internally, so IMO they should not be taken hostage of your design mistakes or your choice of libraries. And yes, if your app fails a typecheck, it means it fails with a fatal error and your users get frustrated. One use case I can think of is during testing, but in this case you can already do the same with a testing framework. Just declare the types in the comments and have the framework use those, but don't let them stand in the way the app actually works. Using strict type checks would be like hard coding your debugging breakpoints, would it not? Best regards, -- Guillaume Rossolini
