Re: Final iteration lost?

On Sun, Aug 11, 2019 at 12:53 PM Leam Hall <[email protected]> wrote:

> On 8/8/19 3:59 PM, John W Higgins wrote:
>
> > On Thu, Aug 8, 2019 at 4:07 AM Leam Hall <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     I'm parsing a data file with each_line, each section starts with a
> line
> >     that ends in ")". Each section has 2-3 subsections, delimited by
> blank
> >     lines. The original test for a new section was:
> >
> >              if line.end_with?(')')
> >
> > The better option here is to create a "job" and have it process the rows
> > as opposed to processing rows and then creating a job
>
> John, just a quick reply on this. I'm still very much a Ruby beginner,
> your solution took me a couple reads to begin to understand. I think
> it's brilliant, and will work to understand it more.
>

I would add one caveat: John's approach adds knowledge about the formatting
to class Job. If I put this into a class, I would probably rather have
classes Job and TextFileJobParser where the latter has knowledge about the
specific formatting (section begins with a line with "(" at end etc.). That
way you can keep class Job for the business logic and have it independent
of file formats. You might store jobs in a JSON or XML format at a later
point in time. If you then lump processing for all the formats into class
Job it is quite likely that it is becoming messy.

Another reason to keep the parsing out of class Job is that you might
require parsing state in the instance which is not otherwise needed for
Job's functionality. So you would have transitional state (the parsing
state) as well as the state required to do Job's job in the same instance.
Not nice, can be confusing and use more resources as necessary.

The grain of salt is that if this is a small application and there is just
the one format it might be OK to put the parsing code into the Job class.

Kind regards

robert

-- 
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can -
without end}
http://blog.rubybestpractices.com/


Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>