Comments on: Better Module Organization

By: Daniel Berger

Daniel Berger — Fri, 31 Jul 2009 00:54:39 +0000

Funny, I was just updating my own ‘use’ library tonight.

http://shards.rubyforge.org/wiki/wiki.pl?Use

1.3.0 is out.

By: charly

charly — Tue, 26 May 2009 19:42:35 +0000

hello Yehuda,

I’ve been advocating a better use of modules as weel last september, quit glad to see those ideas getting into 3.0

My suggestion at the time, for what it’s worth, was to put the class base methods in a module called “module core” since they are de-core-ated. It made sense with the design pattern it is using.

Check my post here:
http://ruby.simapse.com/2008/10/rails-refactoring-exercise.html

I used active record for this rails refactoring exercise.
Trying this out with the AR i remember seeing the all tests pass… to my great surprise.

I’ll look more closely to the hole setup and use dsl.

By: Collin Miller

Collin Miller — Sun, 12 Apr 2009 09:02:54 +0000

Ace!

I’ve been thinking for a while now, that the “acts_as_*” pattern would be a whole lot nicer if it was: SomeClass.acts_as(List) instead of SomeClass.acts_as_list

That way any object with the right sub-modules can be a behavior and as an end-user I have some notion of how the code is organized. There may be conventions within the acts_as_* world, but when the strategy is let library authors decide how to reach into core classes it’s one heck of a crapshoot.

By: lolcatz

lolcatz — Sat, 11 Apr 2009 20:28:16 +0000

Just out of curiosity, when you guys going to merge 3-0 branch and all your forks to rails/master?

Do you think it’s possible to release 3.0 in May?..

By: wycats

wycats — Wed, 08 Apr 2009 16:27:24 +0000

@antonin it does quite a bit more than the normal include, which I described a bit. For one, it supports dependencies, which cannot be done with include because the included hook is run AFTER the module is included (which confounds the ability to override methods in a dependency and call super).

It also simplifies the included hook/class_eval pattern. The point is to make it a lot easier to mentally map what’s going on, without a bunch of boilerplate that you have to grok every time.

By: Brian

Brian — Wed, 08 Apr 2009 16:02:08 +0000

So what does the use method look like? Does it, unlike the original code, include the dependencies rather than erroring out? It seems so based on your last code snippets.

If so, are there potential problems when you don’t know exactly what modules are being included? It seems useful to know that AbstractController::Renderer is included, and with this code (if it does automatically include dependencies) I’d have to know what all of the modules’ dependencies are in order to determine what functionality I’ve got mixed in. Not a hard thing to do, obviously, but I wonder what your thoughts are.

Also, I’m a bit confused as to why ActionController::Renderer is not required in the first example but required in the second, but that may be due to a lack of context.

As an aside, your blog is great; this stuff is very interesting to me! I’d be even happier with more frequent posts *nudge nudge*.

By: Bob Aman

Bob Aman — Wed, 08 Apr 2009 12:30:10 +0000

I like it. I’ve run into this problem a lot myself, and I might have to borrow some of this.

By: Antonin

Antonin — Wed, 08 Apr 2009 07:19:54 +0000

I like the idea of abstracting repeated idioms like included/class_eval thing but what’s the point of redefining the “include” method to “use” if it does the same thing, Does is check that the included module wasn’t previously included ? Else what’s the point ?

Do thoses module helpers gets its own separate lib of does it fall into ActiveSupport ?