From: Michel Demazure on
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


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
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
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
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).