DCI and ruby

Ruby
1

The following post is interesting

In the DCI way, an object can be assigned a role by extending a module
bringing the methods pertaining to this role

obj = Klass.new
obj extend Role

But, how to change roles, without cluttering the metaclass hierarchy ?

obj unextend Role # ?
obj extend NewRole

But, even with an ah-hoc unextend, one needs to remember the old role.
Therefore, what about a ‘temp_extend Module’ method, which clears the
previous ‘temp_extension’ ?

_md

2

On Sun, Feb 13, 2011 at 5:51 AM, Michel D. [email protected]
wrote:

But, how to change roles, without cluttering the metaclass hierarchy ?

I read the article and found it interesting as well. How about
mixology? (http://rubyforge.org/projects/mixology/) It lets you mix in
and unmix to get the old behavior back.

Cheers,
Jason

3

Hm, interesting question. Can you give an example of when you might need
to
un-assign a role? It only lasts for the length of the request anyway, if
I
understand correctly.

4

Andrew W. wrote in post #981397:

Hm, interesting question. Can you give an example of when you might need
to
un-assign a role? It only lasts for the length of the request anyway, if
I
understand correctly.

I was thinking in general terms, not in a Rails setting. Just thinking
about how the DCI idea could be useful in my work, as it seems very
ruby-esque (duck typing > classing).

I can imagine cases where the given class has a given instance method,
say :foo. The object is assigned a role where the :foo method is
redefined. Then you assign a new role, which uses the generic :foo
method and you want it back.

If you use mix/unmix, then when you assign (= mix) a role, you have to
know if you have an already mixed-in role to unmix and which one. You
need to distinguish two types of mixins, permanent and temporary. Just a
small addition to the mechanism indeed, unless you want to mix (!)
things (including/excluding in roles or vice versa). Difficult to say
more without real examples.

Has this question something to do with the ‘refinement’ proposal ?

_md

5

Andrew W. wrote in post #981397:

Hm, interesting question. Can you give an example of when you might need
to
un-assign a role? It only lasts for the length of the request anyway, if
I
understand correctly.

One example is a page which consists of many different “boxes”, each
associated with a different role. I solve it with Cells at the moment.
Each cell extends the object. I think it would be good in this case to
unextend the object after the cell finishes rendering.

Another example might be a Rails app which doesn’t use Active Record but
keeps objects in memory (like Madeleine). In this case the object is
already initialized and if we don’t unextend the role then we will have
most of the roles mixed after some requests.

Mixology gem can probably help here.

6

On Feb 13, 2011, at 02:51 , Michel D. wrote:

But, how to change roles, without cluttering the metaclass hierarchy ?

obj unextend Role # ?

I wrote the ‘un’ gem which has uninclude and unextend. Passes tests on
1.8 and 1.9.

Tho I’ve got to say that I’m not sure what DCI does that decorations
don’t. Seems this can all be done via composition and delegation quite
easily. shrug

7

Ryan D. wrote in post #981451:

Tho I’ve got to say that I’m not sure what DCI does that decorations
don’t. Seems this can all be done via composition and delegation quite
easily. shrug

DCI and composition can work together very nicely in my opinion. In this
context DCI just gives you a way of not declaring all of the delegations
in one class, but split it and use and role at a time.

Let’s assume that in the Redmine codebase it’s the User class that is
responsible for most of the UI actions. In that case User would contain
lots of associations:

has_many :issues, :owned_issues, :projects, :comments, :attachments

It would probably delegate some of the logic to classes like
ProjectManager, IssueOwner, IssueReporter etc.

It’s all mixed together at the class level.

With DCI you would still have the “composition” classes/modules, but now
they will be injected runtime, so no need to have them in one place in
the User class.

I’m not sure if it’s good or bad. I like this way of thinking that now
I’m talking to “this” role of the user object, so I don’t care about
other roles. I also like the fact that the base User class is now much
smaller.

8

unsubscribe

----- Original Message ----