Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.lang.php
Subject: Re: PHP Warning: extract() expects parameter 1 to be array
Date: Sun, 21 Aug 2016 16:55:31 +0100
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <87pop2unf0.fsf@bsb.me.uk>
References: <2d416b5e-e923-4d44-bcbf-6956d2436ef2@googlegroups.com> <200820161821375934%timstreater@greenbee.net> <npa6ob$q4u$1@solani.org> <18d88f90-6b3b-4e2f-8b9f-5cb9c69176a1@googlegroups.com> <210820161026199601%timstreater@greenbee.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="017616aa25f81ec581c44d76d61ba2f3"; logging-data="6568"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+lZ04NvPx33FfufFthACogjGkCs5QZ6AA="
Cancel-Lock: sha1:bz5jVAagluvvAFsUxGTI2qR6EHo= sha1:1yDPb6IMrlCHikFXeEcTMjvvoHM=
X-BSB-Auth: 1.3a8ef0409093db1acb38.20160821165531BST.87pop2unf0.fsf@bsb.me.uk
Xref: csiph.com comp.lang.php:16967

Tim Streater <timstreater@greenbee.net> writes:

> In article <18d88f90-6b3b-4e2f-8b9f-5cb9c69176a1@googlegroups.com>,
> Alla <modelling.data@gmail.com> wrote:
>
>>On Saturday, August 20, 2016 at 9:15:44 PM UTC+3, Christoph M. Becker wrote:
>>> On 20.08.2016 at 19:21, Tim Streater wrote:
>>>
>>> > In article <2d416b5e-e923-4d44-bcbf-6956d2436ef2@googlegroups.com>,
>>> > Alla <modelling.data@gmail.com> wrote:
>>> > >>                $new_entry = fgetcsv($open_file, 0, "\t");
>>> > > Why are you not checking that fgetcsv didn't return a boolean?
>>> > > I could also ask why your program is such a convoluted
>>> if/then/else
>>> > mess but I can't be bothered.
>>>
>>> Alla is learning.  No one is born a master. :-)
>
>>Christoph and Rudy, Thank you very much!
>> As to Tim's message, which I can see only as a quotation here, I am
>> fine with all criticism, even harsh one, but if it contains correct
>> remarks, as Tim's
>> message does, - it is also very helpful in learning. And I do agree
>>about the "convoluted mess"; I am struggling with this issue,
>>including in my C coding experience. I am in the processes, hopefully
>> a successful
>>one eventually :)
>
> There was a time around 1980 when computer science students were
> apparently being told that single-entry-single-exit was the way to
> write functions and procedures. This approach was assisted by the fact
> that Pascal didn't even have a return statement.
>
> I've always found this approach to be foolish as it increases
> complexity for no benefit,

No benefit (in all cases) is a little strong.  In some situation it can
be useful.  For example when you have very limited debug facilities
being able to add print or logging call in one place can be helpful.
The problem comes from it being made a rule, with no thought put into
what the costs might be compared to any benefits.

<snip>
> In my view, you should be doing thus:
>
> // Start with all tests for conditions that prevent the program being
> run
>
> if  ($argc<2)
>     {
>     echo "Please, provide a path to a file\n";
>     exit ()
>     }
>
> if  (!file_exists($file))
>     {
>     echo "Sorry, there is no such file $file\n";
>     exit ()
>     }
>
> if  (!is_readable($file))
>     {
>     echo "$file is not readable\n";
>     exit ()
>     }
>
> // other tests etc, then finally:
>
> $open_file = fopen($file, "r");
> if  ($open_file===false)
>     {
>     echo "Sorry, couldn't open $file\n";
>     exit ();
>     }
>
> // Now comes the real meat of the program
>
> while (...)
>     {
>
>     // Main work is here
>
>     }

Generally a good plan, but in this case I prefer the "more structured"
version:

if ($argc < 2)
    echo "Please, provide a path to a file\n";
else if (!file_exists($file))
    echo "Sorry, there is no such file $file\n";
else if (!is_readable($file))
    echo "$file is not readable\n";
...
else if (($open_file = fopen($file, "r")) === false)
    echo "Sorry, couldn't open $file\n";
else {
    // All ok.  Let's get on with it...

    while (...)
    {
    // Main work is here
    }
}

Obviously put the {} back if your style rules require them.

(You probably did this only for the purposes example, but since many
people might see this, I'd point out that it's usually better just to
try to open a file.  Testing for specific problem before hand is going
to work 99.9999% of the time, but it introduces a race condition that
is, to my mind, inelegant.)

<snip>
-- 
Ben.