Re: Final iteration lost?

Leam Hall <[email protected]> Thu, 15 Aug 2019 07:31:51 -0400
Newsgroups gmane.comp.lang.ruby.general
Message-ID <[email protected]>
On 8/11/19 9:53 AM, Robert Klemme wrote:
> 
> 
> On Sun, Aug 11, 2019 at 12:53 PM Leam Hall <[email protected] 
> <mailto:[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]>
>      > <mailto:[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

Here's the current iteration of that section. The Job class 
initialization takes some data and sets other values to nil. This is due 
to some older jobs not having those data sections. The sections are 
always in order.

###

data = Hash.new
jobs_file = 'input/leamhall_jobs.txt'
File.foreach(jobs_file) { |line|
   line.chomp!.strip!
   next if line.empty?
   if line.end_with?(')')
     data.clear
     header_array  = line.split(',')
     title         = header_array.shift
     dates         = header_array.pop
     start_date, end_date = set_dates(dates)
     employer      = header_array.join(' ').strip!
     data = {  start_date: start_date, end_date: end_date,
               title: title, employer: employer }
     current_job   = Job.new(data)
     jobs << current_job
   elsif current_job.blurb.nil?
     current_job.blurb = line
   elsif current_job.tech.nil?
     current_job.tech  = line
   else
     current_job.extra = line
   end
}




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