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
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
nevertheless.
class Base
@class_all_enum_objects = 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
defined in Enumerable and this module contains all the enumerating
methods which are based on #each (e.g. find_all, inject, map).
def find_all(*condition_strings,&code_block)
if block_given?
find_array = super
else
find_array = # process condition strings (syntactic sugar) here.
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 = [])
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
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<=> definition). 5) I want to be able to define new functions
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.
Yes, you are correct (e.errors is a typo - should be s.errors), they are
equivalent.
Sorry, that was a typo. Thanks for catching that.
I think 'sort' is the main reason for my 'easy way out'. Plus the use of
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
the easy way out in the example above. Even if you would need the
String argument eval solution for sorting it would not be necessary for
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 classes
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
ordering. What I mean is this: you need to modify a class to achieve a
particular ordering. Now the standard behavior of sorting has changed
and you can never tell what ordering you will get by only looking at a
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
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|
"x.#{f}"}.join(', ')}]}}"
end
MAIN = Sorter
foo, :bar)
...
sorted = 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
compiling only the field extraction:
def FieldExtractor(*field)
eval "lambda {|x| [#{fields.map {|f| "x.#{f}"}.join(', ')}]}"
end
MAIN = FieldExtractor
foo, :bar)
...
sorted = 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 = 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 = 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 == 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)
# => [[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)')
# => [["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)')
# => [["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)
# => [["efec", 6000, 4], ["efec", 1500, 3], ["ufec", 3000, 1], ["ufec",
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
to fields and not just one level. In my world this would look like
p Slot.enum.sort_by {|x| [x.rate,
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
not look that much shorter.
# total errors of all slots.
p Slot.enum.sum_total_eoc(':error_info.sum_total_eoc
num_errors)')
# => 13200
# slots that have>= 3000 total errors.
p Slot.enum.find_all(':error_info.sum_total_eoc
num_errors)>=
3000').collect
slot_num)
# => [[1], [4]]
# use a variable for sort parameter.
var = ':slot_num'
p Slot.enum.sort("#{var}").collect("#{var}")
# => [[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 = ':slot_num'
p Slot.enum{}.sort(var).collect(var)
# => [[1], [3], [4], [8]]
# slots that have>= 2500 errors in a single time period.
p Slot.enum.find_all(":error_info.any?
num_errors>=
2500)").collect
slot_num)
# => Exceptions galore! my simple 'parser' breaks down. will have touse
the 'old fashioned way' of a code block. maybe I will try to get this to
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 to
build an array), so there is enum_only{} which enumerates only the given
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
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
do you want to make classes keep track of all their instances? This
essentially makes classes global variables - but less obvious. During
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
there is no clear demarcation. If you want automated tracking of
instances there are other options, e.g.
class InstanceTracker
def initialize
@all = Hash.new {|h,k| h[k] = []}
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 <= cl}
self
else
Enumerator.new(self, :each_sub_classes, cl)
end
end
end
it = InstanceTracker.new
it.new(Foo, 1, 2)
it.each_class(Foo).find_all {|f| f.size > 0}
etc.
Kind regards
robert
