From: James Edward Gray II <james@...>
Date: 2009-11-15T01:58:03+09:00
Subject: Re: Naming conventions -- was: Re: DRYing a Regex

On Nov 13, 2009, at 10:27 PM, Marnen Laibow-Koser wrote:

> James Edward Gray II wrote:
> [...]
>>> Even Apps Hungarian is not a great idea in OO code.  Instead, just use 
>>> the type system, so that distance would be a Kilometer object and 
>>> correction would be a Foot object.  Kilometer.+(foot) could then either 
>>> raise an exception or invoke a conversion.
>> 
>> I would like to see us move away from considering classes to be types at 
>> all in Ruby.  Who knows what modules an object has mixed into it and who 
>> knows what singleton methods are defined on it.
> 
> 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.  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().

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

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

James Edward Gray II