Hi,
Am 22.02.2012 20:04, schrieb Larry Garfield:
On 2/22/12 12:37 PM, Peter Lind wrote:
I would also support this. There's a myriad reasons why something may
return NULL or FALSE when you expect it to return an object, some of them
even legitimate. Any function/method whose documentation line is "returns
the foo object, or NULL if someone screwed up and there isn't one" is
perfectly reasonable in many cases, IMO, but makes all chains a potential
fatal. An exception would make a lot more sense, and allow us to
centralize handling of such "exceptional" cases rather than throwing
if-checks everywhere. (Which is exactly what exceptions are for.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Seems to me this change would encourage bad habits (breaking the law of
Demeter) which would personally put me against it.
Regards
Peter
How? What bad habit does this encourage?
The law of demeter (as mentioned). In short: Always interact with your
direct neighbours only keeps the dependencies always obvious (or
something like this). As a side effect you'll not see such chains, if
you follow this rule.
In my opinion calling a method on "null" sounds like a bug. If you want
to chain method calls _ensure_ they _always_ returns an object of the
expected type, or (if null is intended) test the object first. Looks
uglier, but thats the price of return values of different types.
What should happen, when an object is returned, but it an instance of
another class? Or on string?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
