On Thu, Apr 28, 2011 at 8:49 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi! > > > it's the same as for the current argument type hinting. >> you can access that information via Reflection >> http://hu2.php.net/manual/en/reflectionparameter.getclass.php >> > > Really? That's how you write your code - do a reflection check before every > call? Nobody does that. > > I didn't said that, probably I shouldn't have mention that, we are both aware of the capabilities of Reflection imo. but it's still true, that it would behave the same way as it does now for the argument type hinting. you didn't reply on that, so I think we agree on that. > > why did we added ppp if people can define in the documentation(or in the >> method name :/) that which method is public and which isn't >> > > Well, this is a good argument, PPP case seems close. Still, PPP is not > really as dynamic as variable types are - PPP picture is much simpler and it > also serves the call target, not the caller - i.e., the caller does not rely > on pretty much anything in PPP, while the target relies on its protected > functions not being called by strangers. > So my main objection is that return typing doesn't actually serve the > caller. > true, and Johannes brought this up also, but I didn't wanted to compare the ppp to return type hinting. I'm just saying that you argument "Why I need being "saved" from documenting my code properly?" isn't apply here. Because by this logic we could remove a lot of things, things which allows the developers to express their code more explicitly. "Anyway, the function code defines the behavior, declaration of return type just ensures function would fail in runtime if your code tries to return unexpected data - but how is it helpful?" as I mentioned I can imagine cases when we can spot errors before actually executing the code, but I don't know enough about the internals to tell that this could be viable or not. > Also, the fact that for PHP is extremely common to return null/false from > methods on error makes a big hole in this concept even if we accepted the > return typing as a counterpart to existing argument typing. E.g., seeing > something like: > function (Foo|Bar|false|null) ugly() > makes me fill dizzy. This doesn't look like something we'd want. > > yeah, but usually you return null/false in case of error when you write procedural code. but since we wouldn't support the return typehint for scalars, maybe we could assume that the only sane people who would use this feature would also do the error handling will through Exceptions (@throws :P). Tyrael
