From: Marnen Laibow-Koser Date: 2009-11-15T04:18:44+09:00 Subject: Re: Naming conventions -- was: Re: DRYing a Regex James Edward Gray II wrote: > On Nov 13, 2009, at 10:27 PM, Marnen Laibow-Koser wrote: > >> >> Do you make much use of singleton mixins or singleton methods in your >> code? I know I don't. > > I have been doing a lot more of mixing modules into individual objects, > yes. I have been more than pleased with the results too. I think it's > something we should all try to do more of. How do you keep such code maintainable? It seems to me that circumventing the class system on a regular basis makes it harder to tell what's what. > I gave a speech about this > at LSRC this year which should show up here someday: > > http://lsrc2009.confreaks.com/ > > I can give a couple of examples. > > I recently ran across some code that had extensions to a core system. > Each extension would reopen the core classes and edit away. > Unfortunately, they had to duplicate a lot of the core code to make > little changes to it. I rewrote the code to allow extensions to > register modules with the core classes. Then when those classes > produced objects, they would mix in any registered modules. This simple > eliminated almost all of the duplication, because the modules were in > the singleton class *in front of* the methods they were modifying. They > could read the arguments and see if they needed to step in with their > modified behavior, or just hand off to super(). Yes, I can see how this would be useful to modify singleton objects. But where a class has more than one or two instances, wouldn't this be extremely confusing? > > I showed another example in my talk where I was trying to create a one > instance configuration object. Originally I did it with a constant and > some clever reopening of the singleton class, but that caused problems > like not being able to easily document this object's API. I switched to > just creating the one instance I needed and immediately mixing in a > module that added the special functionality and it solved all the > problems I had. You can document a module just fine. (The example is > in my slides, if you want to see it: > http://blog.grayproductions.net/articles/lone_star_rubyconf_slides.) > I'll take a look. > I think we should do more of this. For example, I think we could return > an Array that mixes in a Paginated module instead of a > PaginatedCollection object that inherits from Array. That feels more > right to me. It's an Array and it has some extra functionality added in > related to pagination. The uses go on and on. That feels hackish to me. If a common type like Array -- of which there could be hundreds of instances in a typical program -- needs extra functionality on some instances, it seems clearer and more intention-revealing to subclass it. Where's the benefit of the singleton mixin here? > >>> A class, which is what >>> people traditionally take for the type, is just one piece of an object's >>> identity. >> >> You're right. But with a proper class system, my point about not >> needing Apps Hungarian in Ruby still stands, I think. Do you disagree? > > I was agreeing with you, yes. I was saying that adding an a_ or s_ to > the beginning of a variable name, assumably to indicate Array or String, > is a damaging practice, because that's not necessarily all you need to > know about the object. I think it promotes the wrong kind of thinking > about Ruby's types. That's Systems Hungarian. Check out Joel's article if you haven't already. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org > > James Edward Gray II -- Posted via http://www.ruby-forum.com/.