Re: Naming conventions -- was: Re: DRYing a Regex

On Nov 14, 2009, at 1:18 PM, Marnen Laibow-Koser wrote:

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

Well, I've said that I don't consider the class system a definition of my types.  This is why.  :)

Honestly, I haven't had trouble with the approach yet.  I can still do an is_a?() check for either the class or the mixed in modules, if I need to check what something can do.

I don't consider this circumventing Ruby's type system.  Ruby's type system handles mixed in modules just fine.  We just tend to think of the inheritance hierarchy as types.  Ruby has a more open definition than that.

Perhaps I'll eventually run into a situation where I regret handling it by mixing modules into objects.  I promise to admit it when I do.  Until then though, all of my experiences with it have been very positive.

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

More confusing than trying to figure out where some code reopened the class you are looking at and rewrote a method to change it's behavior?  Not to me.  At least Ruby will tell me about mixed in modules!

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

Where's the benefit of subclassing?  I thought it was pretty well accepted that subclassing is pretty tight coupling and can be pretty fragile.  Many Design Patterns are about avoiding subclassing for just that reason, right?

If you subclass, you've already made some heavy decisions.  You are saying pagination returns a special Array.  What do you do when I want a paginated SortedSet (from Ruby's standard library)?  You will be pretty much starting over, building another specialized subclass, I assume.  I'll be thinking, "What changes does my Paginated module need to support SortedSet?"  I would rather be in that position, that's all.

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

Yes, I've read it.  I'm still agreeing with you.  :)

My examples, a and s for (I assume) Array and String, are the actual examples that started this discussion.  That's what I feel should be discouraged and, yes, it's called Systems Hungarian.

I can see a little value in Apps Hungarian, but, again agreeing with you, I would rather build the protection into the code than the variable names. Or just teach the code to do the right thing, like converting to a common measurement and then combining values.

I do see that I quoted pretty badly above though, which is probably what made this so confusing.  Sorry!

James Edward Gray II