Re: setting local variables in a binding

Robert Klemme wrote in post #947187:
> 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.

Your remarks are always useful, and I appreciate them.

>> 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).
>

True, especially since I also include the module in a subclass of Array,
not just a subclass of Enumerator.

> 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?

Correct. All of the modified methods such as sort, find_all, collect,
all?, etc. are in EnumeratorModifierEOC although I presented only one or
two methods. I originally had modified Array and Enumerator and aliased
the methods for normal code block use (non syntactic sugar), but after
some correspondence in this forum decided that it was not a good idea to
do that. So now I modify the methods in a subclass and call super to
pass on the code block if syntactic sugar (passed parameter string(s) or
symbol(s)) is not used.

> 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...

I do not need to modify a class to achieve a particular ordering, I need
to define a class. The default ordering is set during the class
definition with attr_accessor and set_comparables_order. However, if I
do modify the class (with the same two methods), the default ordering
will change.

Or did you mean that a subclass can / will have a different default sort
order than it's superclass? This can certainly be the case and is
actually encouraged to add flexibility. Are these element of a bad
design? If so, why? (You can be brief, hopefully I will understand.)

> ...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.

True, you would have to look at the attr_accessor and
set_comparables_order methods elsewhere in the code (possibly multiple
places). If these have been modified dynamically, the
ClassName#comparables method can be used to return the default
comparables.

> enum.sort_by {|x| [x.field_1, x.field_2]}
>
> which is pretty short, readable and efficient.

When I was looking over the Enumerable methods that I wanted to modify,
I skipped sort_by for some reason. You are right, it is pretty short and
readable. May need to take another look at it.

> 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.

True. I said this to make the point that I have thought of things that I
need to do to try to keep things from breaking since Ruby is dynamic. I
think you are saying that by coding this way, I am making it tough on
myself since Ruby is dynamic. Hmmm, need to think about this, because I
know that there will be cases out there that I do not think to cover. I
guess this is a way to tell a good design from a bad one.

> 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?

When I was learing Ruby, I came across ObjectSpace.each_object and
thought that since Ruby makes this method available, why not use it
instead of setting up my own containers? So early versions of the code
used ObjectSpace. Then I discovered self.inherited and class instance
variables.  I decided to use self.inherited to pass along the values of
certain class instance variables that I want inherited (and slightly
modified for that subclass). Since keeping track of child classes was
fairly easy with self.inherited and I could also use it to initialize
@class_all_enum_objects, I dropped the use of ObjectSpace. It seems like
ObjectSpace would be less efficient too.

> This essentially makes classes global variables - but less obvious.

Never thought of that. See my comments below on my lack of having to
interface with other users' code.

> 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.

I do provide a delete method that will delete an EOC object from the
@class_all_enum_objects class instance variable. I also even provide a
recursive delete object method which deletes the EOC object and any EOC
object that it finds as an attribute (for example, a Slot object can
have an attribute :xp which is an Xp object (transponder, in case you
are wondering).

>If you want automated tracking of
> instances there are other options, e.g.
>
> class InstanceTracker
>   ... lines of code
> > end
>
> it = InstanceTracker.new
>
> it.new(Foo, 1, 2)
> it.each_class(Foo).find_all {|f| f.size > 0}
>

I see, but why have a seperate class for this? Aren't you doing the same
thing?

I think that the reason that my code is the way it is, is partially due
to the fact that I am writing my code in isolation; I do
not have to interface to other code to perform a broader function. In
fact, I have no experience writing code with any kind of interface
(explains a lot, huh?). Well, I guess I do use gems, so I am not in
total isolation, and at least I have given it some thought since I
turned away from mofidying Array and Enumerator directly.

js

-- 
Posted via http://www.ruby-forum.com/.