"Code must be Chunkable"
in [Ruby]
|
From: Michel Demazure on 11 Feb 2010 09:18 Thomas Sawyer wrote: > > Notice the remarked #unextend lines. For a real implementation of DCI, > we would want to remove these roles once we used them, but Ruby's > extend doesn't allow that, of course. > Could you not extend again by a Module which would undefine the added methods ? -- Posted via http://www.ruby-forum.com/.
From: Intransition on 11 Feb 2010 09:22 On Feb 11, 4:45 am, Brian Candler <b.cand...(a)pobox.com> wrote: > Thomas Sawyer wrote: > > Coplien does > > an awful job of explaining things. Trygve, despite his age, does a > > much better job. > > I'd say "Trygve, because of his age, does a much better job" :-) Good point. I agree.
From: Brian Candler on 11 Feb 2010 11:29 Michel Demazure wrote: > Could you not extend again by a Module which would undefine the added > methods ? It's a moot point in the common case where objects don't persist (i.e. Account.find(id) creates a new object from info in the database) I think it could be done more cleanly with a facade/proxy object. This would have an added advantage that concrete methods in the underlying object could not call back to the context (which they should not be able to do; only the injected methods should do this) -- Posted via http://www.ruby-forum.com/.
From: Michel Demazure on 11 Feb 2010 12:58 Brian Candler wrote: > Michel Demazure wrote: >> Could you not extend again by a Module which would undefine the added >> methods ? > > It's a moot point in the common case where objects don't persist (i.e. > Account.find(id) creates a new object from info in the database) > > I think it could be done more cleanly with a facade/proxy object. This > would have an added advantage that concrete methods in the underlying > object could not call back to the context (which they should not be able > to do; only the injected methods should do this) I agree. M. -- Posted via http://www.ruby-forum.com/.
From: Intransition on 11 Feb 2010 15:33
On Feb 11, 11:29 am, Brian Candler <b.cand...(a)pobox.com> wrote: > It's a moot point in the common case where objects don't persist (i.e. > Account.find(id) creates a new object from info in the database) > > I think it could be done more cleanly with a facade/proxy object. This > would have an added advantage that concrete methods in the underlying > object could not call back to the context (which they should not be able > to do; only the injected methods should do this) I played around with the concepts a bit more. You can see what I came up with here: http://gist.github.com/301909 I did a couple of interesting things (though I suppose I may be taking it too far) I thought of a Context as a Scene in a play, in which I defined the roles upfront (ie. at the class level) -- I use the Anise gem to do this, btw. And, despite what was said in the lecture, I was able to use polymorphism with regard to the roles. This approach seems very interesting. I was able to define two methods of the same name that can act on the same object, but dependent on the role it plays. Thus the Context has a method that is dispatched to all the roles. While my code is from perfect the approach itself does seem like it could be useful for large applications. (It feels like overkill for small libraries though). |