Hi! >> I've also used it because it can adequately show the differences in how each >> of the following options work: >> >> 1. Do covariant return types; check them at definition time >> 2. Do covariant return types; check them at runtime >> 3. Do invariant return types; check them at definition time
My opinion is that on some level it doesn't matter too much. The type errors by itself are quite rare among the errors one can make in the program, and usually found and fixed rather easily [1]. Errors in return types - i.e. mismatch between declaration and code in your own code located compactly on the screen - would be even rarer. Errors where the difference is between covariant and invariant classes - and thus use cases where such usage is helpful to prevent them - in my opinion, would be so vanishingly rare that most people would never really need it, and probably would spend much more time figuring out the right types to set on the return values that it will ever save them on debugging. I suspect except for the simplest cases these would be used more for documentation/"feel good" purposes than for anything else. Thus, taken practically, I think the option that has minimal impact on the existing code, its speed and complexity should be taken. If it requires reducing the expressiveness to the option 3, I don't think it is a huge loss. I'm not sure though what is involved in "runtime checking" and what would be the consequences - i.e., what will be checked at runtime and which runtime will it be? In PHP, mostly everything is "runtime" strictly speaking, so some clarification here would help. [1] E.g. check out this one: http://vimeo.com/74354480 There is a vivid debate about many conclusiong derived there but I think empirical evidence is worth considering however is your stand on the conclusions. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
