Ruby Modularity

nkallen_: nkallen_: anyway, i want to stress that we basically agree about things so i want to be sure that the tone of the blog post is such
[7:25pm] nkallen_: [7:17pm] nkallen_: i would argue that what you do in rails 3 (according to these tweets I've read)
[7:25pm] nkallen_: [7:17pm] nkallen_: is exactly what I propose... this is just how one might do it in Ruby
[7:25pm] nkallen_: [7:18pm] nkallen_: but my point is conceptual and not about ruby
[7:25pm] nkallen_: [7:18pm] nkallen_: it applies to every oo language and also I might argue to functional languages
[7:25pm] nkallen_: [7:18pm] nkallen_: which is to structure a program around the ability to layer on enhanced functionality and ensure that no assumptions are hardcoded by abstracting over the manufacture of objects
[7:25pm] nkallen_: [7:19pm] nkallen_: in the literature, these techniques are called DI, decorators, and factories.
[7:25pm] nkallen_: [7:20pm] nkallen_: i like these terms because they reflect the concepts that are at work. because ruby might have little ceremony (you don't ever need to name a thing "Factory") doesn't mean the concept of "any object that responds to #new and returns an object that obeys such-and-such ducktype"
[7:25pm] nkallen_: [7:20pm] nkallen_: is not a real and useful concept to think about.
[7:25pm] nkallen_: [7:21pm] nkallen_: and it's especially important for polyglots.
[7:25pm] nkallen_: [7:21pm] nkallen_: are you even here? am i talking into the void?
[7:26pm] wycats_: I'm here!
[7:26pm] nkallen_: the other reason these names are important is because although you've chosen wonderful and valid techniques by using mixins and defining classes
[7:26pm] wycats_: Do you see me?
[7:26pm] nkallen_: yes
[7:26pm] nkallen_: another totally valid technique in ruby would be to use composition not inheritance.
[7:26pm] wycats_: Agree
[7:26pm] nkallen_: and in this case you would create an object that responded to #new but was not a class at all
[7:26pm] nkallen_: (probably)
[7:26pm] wycats_: My concern is about adoption
[7:27pm] nkallen_: explain
[7:27pm] wycats_: By calling these things ceremony-laden terms we reduce adoption
[7:27pm] nkallen_: oh
[7:27pm] wycats_: Forgive my slowness
[7:27pm] nkallen_: (no worries)
[7:27pm] wycats_: iPhone
[7:27pm] nkallen_: lol
[7:27pm] nkallen_: this is unfair
[7:27pm] wycats_:
[7:27pm] wycats_: Ha
[7:27pm] nkallen_: anyway, if you want to avoid using jargon because you're using some didactic technique for a certain type of audience, be my guest!
[7:28pm] wycats_: I think the jargon mainly exists because of the complexity in java
[7:29pm] nkallen_: to me it's important to synthesize that there is basically one set of tools for making OO code modular, but there are several concrete ways to implement those tools
[7:29pm] wycats_: In what sense is passing parameters "injection"?
[7:29pm] nkallen_: and the several ways exist not only within a language but across languages
[7:29pm] nkallen_: and so speaking conceptually about these is important if one wants to understand the essential unity of these ideas.
[7:30pm] wycats_: I'd tend to argue that Ruby provides an ideal set of tools to
[7:30pm] wycats_: Implement these patterns
[7:30pm] nkallen_: I would certainly argue that Ruby does it well but that despite that these tools are vastly underutilized.
[7:31pm] wycats_: People dislike java not because of these concepts, but because of the need to have a lot of chrome
[7:31pm] wycats_: As you demonstrated
[7:31pm] nkallen_: i don't think it's one or the other. acts_as... is a lot of chrome.
[7:31pm] nkallen_: def timeout; 1.second; end is chrome
[7:32pm] nkallen_: here would be my claim about rubyists:
[7:32pm] wycats_: It's easy to abstract a lot of the chrome
[7:32pm] nkallen_: many ruby programs write little scripts or write MVC apps. they are unfamiliar with straight up OO software.
[7:32pm] nkallen_: s/programs/programmers
[7:32pm] wycats_: Agree
[7:33pm] nkallen_: so it's unusual to see these techniques in Ruby code despite that they're easy to do in Ruby, easier than Java for sure, and comparable to Scala.
[7:33pm] wycats_: See rails 2.3 megafails
[7:33pm] wycats_: Easier than scala
[7:33pm] wycats_: See our Twitter convo
[7:33pm] nkallen_: you can use inheritance more flexibly in Ruby than in Scala, that is for sure
[7:34pm] nkallen_: to echo your point, the structure of Rails 2.x is unmodular.
[7:34pm] wycats_: that's the benefit of dynamism
[7:34pm] wycats_: Not alias_method_chain
[7:34pm] nkallen_: it is unmodular because it does not use sound techniques of modularity.
[7:34pm] wycats_: Agree
[7:35pm] nkallen_: and a consequence of that is that it is totally unsurprising that gems and plugins break totally at even minor version upgrades
[7:35pm] wycats_: We'll get better with 3 but conceptually each trait is usable alone
[7:35pm] wycats_: Agree
[7:35pm] nkallen_: because the "vector of modularity" is alias_method_chain-ing private methods
[7:36pm] wycats_: Yeah... And failure to obey LSP once done
[7:36pm] wycats_: Liskov substitution
[7:37pm] nkallen_: yes
[7:37pm] nkallen_: i'd like to see examples of lsp violations that you're thinking of
[7:38pm] nkallen_: but let's do that some other time.
[7:38pm] nkallen_: let me address one more point because i can type faster than you 
[7:38pm] nkallen_: i use the word injection as synonymous with parameterization. why?
[7:38pm] wycats_: People easily override render and forget to return the parent's value
[7:38pm] wycats_: That's the most obvious
[7:39pm] nkallen_: because there are many techniques to inject a dependency:f
[7:39pm] nkallen_: formal parameters to a method, formal parameters to a constructor, setters on an instance
[7:39pm] wycats_: Injection sounds "hard"
[7:39pm] wycats_: Not hard difficult
[7:39pm] nkallen_: listen wycats: use whatever didactic techniques you want
[7:40pm] nkallen_: i'm interested in broad patterns and concepts more than introducing beginner programmers to things they're going to love when they get the hang of them.
[7:40pm] wycats_: You misunderstand
[7:40pm] wycats_: I don't feel
[7:40pm] wycats_: Injections describes it well in ruby
[7:40pm] nkallen_: since, in ruby, you can still inject dependencies using several techniques:
[7:40pm] wycats_: I'm boring you with my fart applications 
[7:40pm] nkallen_: def initialize(something_factory); end
[7:41pm] nkallen_: def set_something_factory(something_factory); end
[7:41pm] nkallen_: and even ...
[7:41pm] wycats_: But why are these parameters special
[7:41pm] nkallen_: acts_as_something :something_factory => ...
[7:41pm] wycats_: Why are they injection vs. Everything else?
[7:41pm] nkallen_: no those other things are injection too
[7:42pm] nkallen_: if we were programming in Pascal, there'd be only two ways of managing dependencies.
[7:42pm] nkallen_: 1. global variables; and 2. parameters to functions
[7:42pm] wycats_: puts "hello" <- injection?
[7:43pm] nkallen_: passing a parameter is a kind of injecting
[7:43pm] nkallen_: does that sound too bullshit?
[7:43pm] wycats_: "hello" is a factory activated with #to_s
[7:43pm] wycats_: No
[7:43pm] nkallen_: i would not say "hello" is a factory activated with #to_s
[7:43pm] wycats_: But why is it useul to talk about it this way?
[7:44pm] nkallen_: because you can speak about structural techniques without overspecifying the implementation.
[7:44pm] nkallen_: also, and maybe more honestly,
[7:44pm] wycats_: What I'm asking is why these parameters are special?
[7:44pm] nkallen_: because Dependency Injection is a widely accepted term when passing in factories as parameters to constructors and setters
[7:45pm] wycats_: I've been seeing some terrible ruby post recently about poor structural techniques, on pivotal and ey's blog
[7:45pm] nkallen_: i read most of the pivotal blog. not sure what you're referring to?
[7:45pm] nkallen_: don't read ey
[7:45pm] nkallen_: *blush*
[7:46pm] wycats_: A recent alias_method_chain oriented post
[7:46pm] nkallen_: oh the one about a module with initialize?
[7:46pm] wycats_: The entire problem could be solved with this pattern
[7:46pm] nkallen_: that's from today i think.
[7:46pm] wycats_: Yesterday
[7:46pm] nkallen_: ok
[7:46pm] wycats_: It makes me cry
[7:46pm] nkallen_: well, i think we agree about a lot of stuff.
[7:47pm] nkallen_: we cry hot tears for unmodular code.
[7:47pm] wycats_: I should get back online later and have this discussion properly
[7:47pm] nkallen_: well tonight i have plans and intend to get good and drunk.
[7:48pm] wycats_: +1
[7:48pm] nkallen_: but i would love to frame this in a way like: here is how to do modularity in ruby, here is some post that uses jargon i disagree with but broad strokes i agree with over there.
[7:48pm] wycats_: I'll email
[7:48pm] wycats_: Yes
[7:48pm] wycats_: That is my plan
[7:48pm] nkallen_: lovely
[7:48pm] wycats_: Peace
[7:49pm] nkallen_: should we pastie this to gist or something?
[7:49pm] nkallen_: @suss wanted a copy
[7:49pm] nkallen_: or is this like some backroom ruby cabal and no one should be able to see unless they've been initiated in to the rites?
[7:50pm] wycats_: Do it