On Tue, Aug 21, 2012 at 12:31 AM, Lester Caine <les...@lsces.co.uk> wrote:
> Morgan L. Owens wrote:
>
>> For the third one ... I'm still waiting for some clarification on how
>>> yield is SUPPOSED to work anyway? If you are using a 'generator' to
>>> return a sequence of data elements, then just what does happen between
>>> each call to the generator ... DOES the generator get called for each
>>> value until something flags there are no more? I still don't see the
>>> advantage of restructuring how things are called to get around a problem
>>> which can just as easily be solved by proper design in the first place.
>>>
>>> Have you even read the RFC yet? Calling a generator function returns an
>> instance
>> of a Generator object. That object has a method interface - described in
>> the
>> RFC. That interface is accessible to the foreach() construct so the loop
>> can
>> iterate over the successive values returned by the object.
>>
>> If by "proper design" you mean your own personal preference for using
>> callbacks,
>> that's also discussed in the RFC. You were told this last month:
>>
>
> You see that is my problem ... WHY is using an existing object instance so
> wrong?
>
> $handle = fopen("../data/clientdatabase.**csv", "r");
> if ( $handle == FALSE) {
> $row = -999;
> } else {
> while (($data = fgetcsv($handle, 800, ",")) !== FALSE) {
> if ( $row ) $contact->ContactRecordLoad( $data );
> $row++;
> }
> fclose($handle);
> }
>
> $contact->ContactRecordLoad( $data ); simply processes the data and then
> throws it away, so why is this so bad? I am just trying to understand why
> my long time method of working is so frond upon, and understand if
> generators will improve the performance of the above 'very heavy' code.
> ContactRecordLoad identifies the 'line type' and then extracts the data
> based on the line type. My NLPG data importer has a dozen processor
> functions selected by the base 'RecordLoad', normally the only problem area
> is translating different date formats into something generic, so the basic
> iteration loop isn't a problem. How will the use of 'yield' make this
> better? Or more important - based on the rfc - why is this so wrong?
>
> No one is frowning on this way of doing things. It's perfectly fine for
the circumstances. Imagine however, that you have a new client, who
provides a different format in their clientdatabase.csv. There are
definitely ways you can handle this in your current code. But with
generators you might be able to do:
function origFormat()
{
$handle = fopen("../data/clientdatabase.csv", "r");
if ( $handle == FALSE) {
return false;
} else {
$row = fgetcsv($handle, 800, ",");
if($row !== false)
yield fgetcsv($handle, 800, ",");
}
}
function strangeFormat()
{
$data = origFormat();
foreach($data as $row)
{
//move some fields around to match the original format
yield $row;
}
}
if($client == 'strange')
$data = strangeFormat();
else
$data = origFormat();
foreach($data as $row)
{
$contact->ContactRecordLoad($data);
}
Another possibility is that you are importing records from another
database, and now you can create a third generator that pulls from the db.
The point is that your data source(the producer) is abstracted from the
consumer, so the consumer doesn't need to have the logic to handle the
different cases inside its (possibly complicated) foreach() loop. And the
producer can be a simple function, rather than an object that implements
the Iterator interface.
Again, the case you've cited is probably not a case where generators give
much advantage. But anytime the logic to produce some data becomes more
complicated (Imagine that you needed to skip some of the lines in the .csv
file based on some kind of filter), then being able to extricate the
producer logic from the consumer logic is helpful.
Thanks,
John
