On Fri, May 3, 2013 at 1:25 AM, Adam Jon Richardson <adamj...@gmail.com>wrote:
>
>
> Currently, sure. Limiting this functionality to the return statement
> seems doable.
>

It's already possible to do so now without any modifications to the core:

function myFunc() {
    $result = array(null, null);
    if ($failureCase) {
        $result[1] = $errorState;
    } else {
        $result[0] = $value;
    {
    return $result;
}

list($result, $error) = myFunc();

Again, all you're asking for beyond that is syntax sugar.


>
> > What you're talking about has many flaws just the same as the
> > existing error handling approach.
> >
> > 1) It depends on order of return values
>
> Sure, but I've found the convention in Go to be one that hasn't caused
> me any trouble (really, the only time I return multiple values is when
> I'm returning an error for impure functions.)
>

And what works in Go may not necessarily work well in PHP.


>
> > 2) It requires breaking BC in a way that will effect every single PHP
> user
> > out there.
>
> How so?
>

Because you would be changing the return value of every single function in
PHP. Anytime you change what a function returns you break BC.


>
> > 3) It requires re-factoring virtually every PHP function, of which PHP
> has
> > thousands upon thousands.
>
> How so? Even just making this possible would allow libraries to wrap
> calls to functions like file() and provide a multiple return
> equivalent that includes the error information. The core functions
> wouldn't have to change.
>
>
If the functions are wrapped to return an array we have to update the
documentation for thousands of functions as well as break user space for
millions of users. Now array_map('file',$files) has a convoluted error
state problem. This isn't as simple of a change as you're making it out to
be.


> > 4) It doesn't make error handling that much easier in PHP, because you
> still
> > have to check the error state regardless of how it's obtained. Believe
> it or
> > not passing back an array is the same thing. All you're describing here
> is
> > syntax sugar that allows the engine to do list comprehension for you on
> the
> > fly.
>
> I might have agreed with you half a year ago, but after coding in a Go
> a while, I disagree. This approach has merit.
>

I'm sure every approach has merit. The problem here is the return on
investment for implementing such a change in PHP. It's a lot of work for
very little benefit.


>
> Adam
>

Reply via email to