On Wed, Mar 11, 2015 at 6:20 PM, botp <botpena / gmail.com> wrote:

> On Wed, Mar 11, 2015 at 4:00 PM, Robert Klemme
> <shortcutter / googlemail.com> wrote:
> > I think I prefer that solution because you can still get your Array via
> > weekdays.to_a and yet do not have to materialize. This is especially
> > convenient if n is large.
>
> you are spot on as always.
>

Thank you!


> but i go on a different route re coding. i dont know why. but that is
> just my style maybe.
> so if i would to address the op's problem, i would just plainly return
> a range of days. this gives me a quick start on coding, like
>
>   def weekdays(n = 5, start = Date.today)
>     start..start+n
>   end
>

But for that you do not really need a method, do you?

then if am concern on processing large number of date values, i could
> then "lazy" it up, like
>
>   weekdays.lazy
>

Oh, I wasn't aware of this. Thank you for the education!


> then i can select wc days i want, eg
>
>   weekdays.lazy.select{|d| !(d.saturday? || d.sunday?)}
>
> and then probably process it
>
>   weekdays.lazy.select{|d| !(d.saturday? || d.sunday?)}.map{|d|
> d.to_s+" "+Date::DAYNAMES[d.wday]}
>
> then i could probably process that further w #each, or stop on #force
> or #to_a,  etc, etc.
>

For me it feels more natural to start with the generator and turn it into
something non lazy on demand (i.e. via #to_a) than first having something
potentially large and turning it into something lazy. It seems more
efficient (at least memory wise) to start with the small generator than
with something else (i.e. you can even invoke #lazy on an Array where you
do have all the values already).


> in a sense,  my brain find it easy to process logic by chaining things
> one at a time...  but then again, it's just for my own simple brain  :
> )
>

I think all our brains are that way (or at least most, you never know). :-)

Kind regards

robert

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