peashutop

[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:26pm] wycats_: My concern is about adoption
[7:27pm] wycats_: By calling these thin