From: John Sikora Date: 2010-10-14T04:23:28+09:00 Subject: 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/.