> Hi,
> 
> I'd like to suggest a new functionality for PHP. I don't know the
internals, and i can't create a patch implementing this. I'm writing here in
case someone likes this idea and write a RFC.
> 
> We've had a problem recently where one of our developers forgot an "if".
> 
> So instead of writing
> if ($obj->image) {
> echo $obj->image->getUrl();
> }
> 
> He wrote:
> echo $obj->image->getUrl();
> 
> Here, locally, it was working cause we had the image. But when we updated
the online version we got a "Fatal error: Call to a member function getUrl()
on a non-object" cause someone didn't upload the image in one of the records
that we're on the home page.
> 
> Fatal errors like this can't be catched by a try/catch. And since this
> getUrl() was not essential for the page, we'd better output an empty
string then having the site offline.
> 
> One might say: "you guys should have tested it better", or "The image
field should be mandatory in the back end."
> And it's true, he should have written that extra "if {}".
> 
> Examining this problem we happened to stumble open Ruby's and
Coffescript's method check.
> Something like this:
> 
> $obj->image?->getUrl()?;
> 
> So my suggestion is:
> 
> Create something like $foo->bar?() or $foo->bar()?, where you don't care
whether the function exists, or if $foo is an object. If it doesn't exist
you just return null.
> I guess there are plenty of systems out there where it's better to output
an empty string than having your site offline, just cause the programmer
couldn't test it completely.
> 
> Thanks for reading it.
> 
> Carlos Rodrigues
I do not like this idea. The error message "Fatal error: Call to a member
function getUrl() on a non-object" is very straight forward, it should tell
you the line the problem is on and everything and a quick glance should spot
the problem quickly. Granted Yes there are cases were it'd be nice to have
an easy work around, but then you run into the problem similar to what the @
has caused for many people, which libraries and general developers start
using it in many places to keep errors form being thrown and you end up with
code that is even harder to debug because no errors are shown. Another
solution that you could have used is to set $obj->image to a singleton
object that is a placeholder for methods like this which might be set...
something like: http://3v4l.org/utBWP

see: http://www.php.net/manual/en/language.oop5.overloading.php#object.call

But even that is a terrible solution, by showing the error fixed a bug...
bugs need to be fixed.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to