Comments on: Better Ruby Idioms

By: Wojciech Kruszewski

Wojciech Kruszewski — Thu, 20 Jan 2011 09:23:04 +0000

Yehuda, you *can’t* do it like this. acts_as_something with ClassMethods and InstanceMethods and abstraction layer is a well established programming patter. It’s enterprise, you see :P

By: Simon

Simon — Wed, 17 Nov 2010 01:40:02 +0000

What defining about an include and extend method?

class Class
def include_and_extend(the_module)
include the_module
extend the_module::ClassMethods
end
end

class Article < ActiveRecord::Base
include_and_extend Yaffle
end

http://glosoli.blogspot.com/2010/11/includeandextend-method-for-ruby.html

By: thoran

thoran — Wed, 05 May 2010 08:19:22 +0000

@wycats: Rather than “overriding include” I might prefer to call it sidestepping or bypassing extend(). In fact I don’t think I like the term include() at all. Is instance_extend() better? Either that or include is kept and the compliment becomes class_include. Generally, though, the usefulness of having everything modular, such that doing the mixin by loading everything dynamically rather than by simply opening a class, is dependent upon the reversability of mixins in Ruby. If it were possible to drop a module in and rip it back out of a class (or another module) again with equal ease, then sure, don’t go opening classes. However, since Module#uninclude/exclude and Module#unextend/retract (And, assuming instance_extend, then we should have #instance_unextend/instance_retract, or alternately we might have Module#class_uninclude/class_exclude.) don’t exist (I ought to know, since I’m writing it in POR (Plain Old Ruby) right now and hence how I got here for the second time when looking for a pre-existing solution.), and since there doesn’t exist a way to easily remove functionality on a per module basis from the ancestors chain, there is insufficient reason to have everything modular and to load it dynamically at this time. The trick to making Module#exclude or Module#retract work properly is to ensure that by removing one module that the functionality provided by another included/extending module isn’t becoming some portion of useless because of a dependency on the one removed. Short of that, it is possible to do this with a little jiggery-pokery. I’m nearly there by way of introspecting on the module and trashing all the methods on the target class or module… Apart from a dependency issue amongst modules, there remains a problem with it remaining in the ancestors chain though, since a reference to the included module remains doing it this way. The alternative to actually banging on the target class or module, and a feature of Ruby I have wanted for about half a decade now is to be able to create context-specific instances of a class where the desired additional (or reduced functionality), such that the functionality exists either actually within or appears to reside within the class of concern, but then outside the context returns to ‘normal’. Something like the eye-popping lambda-lambda-lambda stuff Raganwald was working on a couple of years ago suffices, but what a pain to have to go to all that trouble, when it isn’t unreasonably included into a language with the sort of dynamism which we expect of Ruby. I was pleased to see that _why also took this approach with Poison. I’m working on something pretty horrible in Ruby to accomplish this as well just now… If it isn’t worse than ghastly I’ll eventually get it onto github. @Peter: The syntax I have at the moment is very much like what you suggest. In your case it would be Post.uses(ActsAsPlugin, :configuration => true) do; stuff; end. In that way Post could optionally act as if it had a plugin. I’m not presently worried about the machine efficiency of doing this because it should not be my concern at this level as to how quicly this operation works. It should be the internals of the language which worries about realising that a particular module has or has not been included already and to cache it somehow.

By: Priit

Priit — Fri, 05 Mar 2010 20:10:51 +0000

@wycats: I think one good overview about AR anti-”super”: http://stackoverflow.com/questions/373731/override-activerecord-attribute-methods and the same thing goes for initialize method as we know. Anyhow, it’s very welcome to see rails 3 become better ruby citizens with optional defaults. Keep up good work about promoting cleaner ruby style.

By: ste

ste — Tue, 19 Jan 2010 16:55:20 +0000

A bit late, but here’s my take:

http://gist.github.com/281080

If someone is still reading this, can you tell me if it makes sense? :-)

By: Adam Durity

Adam Durity — Sat, 12 Dec 2009 01:50:52 +0000

I must agree whole heartedly. When I first started with Rails, though I had worked with Ruby prior, I didn’t have a grasp on some concepts. I remember slugging through AuthLogic code trying to interpret it. While Ben Johnson did a great job on the library, it is wrought with the kind of patterns that you describe above, making it tough to review.

Hopefully this clears it up for some newer folks.

By: Marek K

Marek K — Mon, 23 Nov 2009 22:44:01 +0000

Nice post, it can clear up this include/extend magic indeed.

But what bothers me is why this overkill pattern with additional module layers came up in the first place. I mean – are there some really good reasons to use the classic act_as_overkill way?

By: Peter Browne

Peter Browne — Fri, 20 Nov 2009 21:46:27 +0000

Speaking of Rails Plugin Idioms…There should be a better, more consistent approach to including plugins.

class Post
include ActsAsPlugin
end

class Post
acts_as_plugin :configuration => true
end

Compare the 2 approaches: #1 is much less “magical” and also has the advantage of not including the acts_as_plugin method into every ActiveRecord class. But obviously, #2 allows for configuration options.

Wouldn’t it be cool if there was a specific API for including plugins that would have the advantages of both approaches. Something like:

class Post
use ActsAsPlugin, :configuration => true
end

By: Eloy Duran

Eloy Duran — Sat, 14 Nov 2009 14:26:51 +0000

Amen

By: Adam Grant

Adam Grant — Sat, 14 Nov 2009 00:25:11 +0000

Holy Cow!

Balls, my friend: clear-thinking BALLS is what you have.

Yeah, I REALLY had a hard time learning how to open classes/extend stuff for the first 2 years of doing Rails work because of this crap. Glad to see someone is as fed up with it as I am!

Hallelujah!