Re: setting local variables in a binding

On 09.10.2010 08:25, John Sikora wrote:

> Robert Klemme wrote:
>> On Fri, Oct 8, 2010 at 6:06 AM, John Sikora<[e-mail]>
>> wrote:
>>
>> So you have something like
>>
>> class Foo
>>    def self.each
>>      yield "whatever"
>>      self
>>    end
>> end
>>
>> ?  Did you also do
>>
>> class Foo
>>    def self.each
>>      yield "whatever"
>>    end
>>
>>    extend Enumerable
>> end
>>
>> ?  That would give you all methods like #find_all etc. for free.
>
> Robert,
> Note that I have kept the code and comments to a minimum here as I did
> not want the post to be even longer. I know that you are quite
> knowledgeable and that you should have little trouble following what I
> am doing - although you might not necessarily understand why I chose to=

> do it this way:

Fluent speaking of Ruby makes it somewhat easier but even for me the=20
length of the post needs some digesting.  So I won't come up with a full =

coverage of everything you wrote for now.  I hope my remarks are useful=20
nevertheless.

> class Base
>    @class_all_enum_objects =3D Array.new
>
>    class<<  self
>      attr_accessor :class_all_enum_objects
>    end
>
>    def initialize
>      self.class.class_all_enum_objects<<  self
>    end
>
>    def self.enum
>       EnumeratorEOC.new(self, :each)
>    end
>
>    def self.each(&code_block)
>      self.class_all_enum_objects.each do |object|
>        yield object
>      end
>    end
> end
>
> module EnumeratorModifierEOC

This should rather be a EnumerableModifierEOC IMHO since #find is=20
defined in Enumerable and this module contains all the enumerating=20
methods which are based on #each (e.g. find_all, inject, map).

>    def find_all(*condition_strings,&code_block)
>       if block_given?
>         find_array =3D super
>       else
>         find_array =3D # process condition strings (syntactic sugar) he=
re.
>       end
>       ArrayEOC.new(find_array)
>    end
>
>    # code for other methods such as sort, min, max, all?, etc. here.
> end
>
> class EnumeratorEOC<  Enumerator         # avoids modifying Enumerator.=

>    include EnumeratorModifierEOC
>
>    def initilize(object, method_sym)
>      super
>    end
> end
>
> class ArrayEOC<  Array                   # avoids modifying Array.
>    include EnumeratorModifierEOC
>
>    def initialize(array =3D [])
>      super(array)
>    end
> end

Although no additional methods are shown (these are presented below if I =

am not mistaken) the purpose of EnumeratorEOC and ArrayEOC is mainly to=20
augment standard types with additional functionality it seems.  Correct?

> To suit my purposes: 1) I want the class itself to keep track of all of=

> the class instances, as shown above, 2) if an attribute has more than
> one value or is more complex than an Array, I prefer to define a class
> for it (inherited from Base) and assign attributes, 3) I want syntactic=

> sugar for enumerables, 4) especially for sort, including default sort
> parameters (min and max get defaults for free as a result of the
> necessary<=3D>  definition). 5) I want to be able to define new functio=
ns
> and to be able to use syntactic sugar with them. See below. 6) I also
> keep track of descendants of classes although this is only partly shown=

> below.  There is a little more on this at the end if anyone is still
> reading.
>
>>
>>> and I have added syntactic sugar to some of the methods. So I can be
>>> lazy (and quick) and write things like:
>>>
>>> Slot.enum.find_all(=EF=BF=BD:slot_num>=3D 8=EF=BF=BD, =EF=BF=BD:slot_=
num<=3D 22=EF=BF=BD, =EF=BF=BD:rate =3D=3D
>>> =EF=BF=BDufec=EF=BF=BD=EF=BF=BD).all?(=EF=BF=BD:errors =3D=3D 0=EF=BF=
=BD)
>>
>> Is this equivalent to
>>
>> enum.find_all {|s| (8..22) =3D=3D=3D s.slot_num&&  s.rate =3D=3D 'ufec=
'}.all?
>> {|s| e.errors =3D=3D 0}
>
> Yes, you are correct (e.errors is a typo - should be s.errors), they ar=
e
> equivalent.

Sorry, that was a typo.  Thanks for catching that.

>> ?  If yes, I do not really see the advantage of your approach.  It's
>> slower needs a similar amount of typing and will detect errors later
>> (at execution time vs. at parse time).
>>>
>> If my assumption above is correct I do not understand where the "easy
>> way out" is.
>>
> I think 'sort' is the main reason for my 'easy way out'. Plus the use o=
f
> additional functions. To illustrate, I have included in the code below
> one such function, 'sum_total_eoc' which is just 'inject' set up for
> addition, but with the ability to use syntactic sugar (of course).

In the code above I do not see any usage of #sort so I don't really see=20
the easy way out in the example above.  Even if you would need the=20
String argument eval solution for sorting it would not be necessary for=20
the code above which uses #find_all and #all?.

> You may or may not agree with my 'easy way out', but here goes:
>
> First, a short explanation: I have attribute and expression comparables=

> for each class. The comparables are compared in the order that they are=

> given in attr_accessor. There is also a class method called
> set_comparables_order that allows the user to re-arrange the order if
> desired (it also allows expressions, not just attributes). Child classe=
s
> inherit the comparables and their order from the parent class. Any new
> attributes defined in attr_accessor in the child class are added to the=

> comparables up front.

A problem of your design is that you change the classes idea of default=20
ordering.  What I mean is this: you need to modify a class to achieve a=20
particular ordering.  Now the standard behavior of sorting has changed=20
and you can never tell what ordering you will get by only looking at a=20
particular piece of code which only contains the call to #sort.

IMHO it would be better to not allow this but instead create a mechanism =

which makes the ordering explicit.  Here is one approach

module EnumeratorModifierEOC # or Enumerable
   def sort_by_fields(*fields)
     sort_by {|x| fields.map {|f| x.send(f)}}
   end
end

This might not be the most efficient solution because of the repeated=20
invocation of #map.  Alternatively you can easily stick with #sort_by by =

doing

enum.sort_by {|x| [x.field_1, x.field_2]}

which is pretty short, readable and efficient.

You could improve this by creating something like a Sorter:

def Sorter(*fields)
   eval "lambda {|enum| enum.sort_by{|x| [#{fields.map {|f|=20
"x.#{f}"}.join(', ')}]}}"
end

MAIN =3D Sorter(:foo, :bar)
=2E..
sorted =3D MAIN[enum]

Now you actually have your eval but you use it to compile code which you =

can then use more often efficiently. :-)

You can even make this more modular by removing the sorting and=20
compiling only the field extraction:

def FieldExtractor(*field)
   eval "lambda {|x| [#{fields.map {|f| "x.#{f}"}.join(', ')}]}"
end

MAIN =3D FieldExtractor(:foo, :bar)
=2E..
sorted =3D enum.sort_by &MAIN

> OK, so what can I do with this? The following are some simplified
> examples:
>
> class Slot<  EnumerableObjectClass::Base
>    attr_accessor :slot_num, :rate, :error_info #<--Array of ErrorInfo
> objects.
>
>    def initialize(slot_num, rate, error_info)
>      super()
>      @slot_num, @rate, @error_info =3D slot_num, rate, error_info
>    end
> end
>
> class ErrorInfo<  EnumerableObjectClass::Base
>    attr_accessor :time_stamp, :num_errors
>
>    def initialize(time_stamp, num_errors)
>      super()
>      @time_stamp, @num_errors =3D time_stamp, num_errors
>    end
> end
>
> Slot.new(3, 'efec', [ErrorInfo.new('10-07-10', 500),
> ErrorInfo.new('10-08-10', 1000)])
> Slot.new(1, 'ufec', [ErrorInfo.new('10-04-10', 1000),
> ErrorInfo.new('10-05-10', 2000)])
> Slot.new(8, 'ufec', [ErrorInfo.new('10-07-10', 1500),
> ErrorInfo.new('10-08-10', 1200)])
> Slot.new(4, 'efec', [ErrorInfo.new('10-07-10', 3500)])
> Slot.enum{}.find(':slot_num =3D=3D 4').error_info<<
> ErrorInfo.new('10-08-10', 2500)
>
> -------------
> # note - most of the examples below do not use variables. However, this=

> is not a limitation and a couple of examples are given that use
> variables.
>
> # default sort is sorted by :slot_num, etc. - order of attr_accessor
> p Slot.enum.sort.collect(:slot_num)
> # =3D>  [[1], [3], [4], [8]]
>
> # sort by total errors.
> p
> Slot.enum.sort(':error_info.sum_total_eoc(:num_errors)').collect(:rate,=

> ':error_info.sum_total_eoc(:num_errors)')
> # =3D>  [["efec", 1500], ["ufec", 2700], ["ufec", 3000], ["efec", 6000]=
]
>
> # sort by rate, total errors.
> p Slot.enum.sort(:rate,
> ':error_info.sum_total_eoc(:num_errors)').collect(:rate,
> ':error_info.sum_total_eoc(:num_errors)')
> # =3D>  [["efec", 1500], ["efec", 6000], ["ufec", 2700], ["ufec", 3000]=
]
>
> # sort by rate, total errors, with total errors sorted high to low by
> ending with '___' triple underscore.
> p Slot.enum.sort(:rate,
> ':error_info.sum_total_eoc(:num_errors)___').collect(:rate,
> ':error_info.sum_total_eoc(:num_errors)', :slot_num)
> # =3D>  [["efec", 6000, 4], ["efec", 1500, 3], ["ufec", 3000, 1], ["ufe=
c",
> 2700,8]]
>
> I think that the above would be hard to do in a one-liner w/o syntactic=

> sugar, so this is my 'easy way out' (although I would not be surprised
> if you came up with one Robert). I think this is pretty easy and it
> saves me time.

The tricky thing I did not consider yet is that you have nested access=20
to fields and not just one level.  In my world this would look like

p Slot.enum.sort_by {|x| [x.rate,=20
x.error_info.sum_total_eoc(:num_errors)___]}.
map {|x| [x.:rate, x.error_info.sum_total_eoc(:num_errors), x.slot_num]}

That's certainly not nice to squeeze on one line but your solution does=20
not look that much shorter.

> # total errors of all slots.
> p Slot.enum.sum_total_eoc(':error_info.sum_total_eoc(:num_errors)')
>   # =3D>  13200
>
> # slots that have>=3D 3000 total errors.
> p Slot.enum.find_all(':error_info.sum_total_eoc(:num_errors)>=3D
> 3000').collect(:slot_num)
> # =3D>  [[1], [4]]
>
> # use a variable for sort parameter.
> var =3D ':slot_num'
> p Slot.enum.sort("#{var}").collect("#{var}")
> # =3D>  [[1], [3], [4], [8]]
>
> # use a variable w/o interpolation - must pass a binding with enum{}
> (which is where this topic started by the way). It is carried along as
> an attribute to ArrayEOC and/or EnumeratorEOC, similar to coparables.
> var =3D ':slot_num'
> p Slot.enum{}.sort(var).collect(var)
> # =3D>  [[1], [3], [4], [8]]
>
> # slots that have>=3D 2500 errors in a single time period.
> p Slot.enum.find_all(":error_info.any?(:num_errors>=3D
> 2500)").collect(:slot_num)
> # =3D>  Exceptions galore! my simple 'parser' breaks down. will have to=
 use
> the 'old fashioned way' of a code block. maybe I will try to get this t=
o
> work in the future.
>
> In case anyone is wondering, if data is input as an Array, it comes out=

> as an ArrayEOC the first time it is read. In the simplified code above,=

> I show a call to super in attr_accessor, but really for the reader part=
,
> I add a line that converts an Array to an ArrayEOC. I do this so I can
> use the ArrayEOC methods as mofified since I want to keep Array's
> methods unmodified.
>
> Since I already use self.inherited, I am able to keep track of
> descendants (a recursive jaunt through the child classes using inject t=
o
> build an array), so there is enum_only{} which enumerates only the give=
n
> class, and enum{} which enumerates the given class and all descendants.=

> I do this because I have a number of units of similar type which follow=

> the classic inheritance OO model (even though it is apparent from posts=

> that this has fallen out of favor). Oh well, it seems that I am behind
> the times on a lot of things.
>
> Oh, and since Ruby is dynamic, I had to modify remove_method and
> undefine_method to remove any comparables, if applicable (there is a
> difference between the two however). And if there are subsequent calls
> to attr_accessor, I have to add those methods to the class comparables
> in the class and any descendant classes. I allow the user to reset the
> comparables to those given in the class and its ancestors. I also tried=

> to make the code reflective, by making the comparables, child_classes,
> descndants, etc. availble.

Your need to redefine remove_method etc. is fallout of your design=20
decision to change the default ordering.  As I said, I believe there are =

better and more efficient designs.

> Writing this code has certainly been fun and
> educational!

That's good!

There are still some things that I didn't yet wrap my head around: why=20
do you want to make classes keep track of all their instances?  This=20
essentially makes classes global variables - but less obvious.  During=20
the course of a program usually you create instances and let forget them =

again.  But in your situation you will keep all instances around and=20
there is no clear demarcation.  If you want automated tracking of=20
instances there are other options, e.g.

class InstanceTracker
   def initialize
     @all =3D Hash.new {|h,k| h[k] =3D []}
   end

   def new(cl,*args, &b)
     @all[cl] << cl.new(*args, &b)
   end

   def clear
     @all.clear
     self
   end

   def clear_class(cl)
     @all.delete(cl)
     self
   end

   include Enumerable

   def each(&b)
     if b
       @all.each {|k,v| v.each(&b)}
       self
     else
       Enumerator.new(self, :each)
     end
   end

   def each_class(cl, &b)
     if b
       @all[cl].each(&b)
       self
     else
       Enumerator.new(self, :each_class, cl)
     end
   end

   def each_sub_classes(cl, &b)
     if b
       @all.each {|k,v| v.each(&b) if k <=3D cl}
       self
     else
       Enumerator.new(self, :each_sub_classes, cl)
     end
   end
end

it =3D InstanceTracker.new

it.new(Foo, 1, 2)
it.each_class(Foo).find_all {|f| f.size > 0}

etc.

Kind regards

	robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/