"Code must be Chunkable"
in [Ruby]
|
From: Brian Candler on 11 Feb 2010 16:52 > 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. I like that. Your base class Role is exactly what I was thinking of as a proxy. > Thus the Context has a method that is dispatched to all the roles. Hmm, that's very clever, but it's a bit too magic for me. It's multicasting (pun not intended); I'd probably just iterate in the context to make it explicit. -- Posted via http://www.ruby-forum.com/.
From: Brian Candler on 11 Feb 2010 17:07 Here's a noddy version (minus annotations) http://gist.github.com/302016 -- Posted via http://www.ruby-forum.com/.
From: Intransition on 11 Feb 2010 20:33 On Feb 11, 5:07 pm, Brian Candler <b.cand...(a)pobox.com> wrote: > Here's a noddy version (minus annotations) > > http://gist.github.com/302016 Very nice --very clean. That close to how first thought about it too, but some of those other ideas came to mind in the processes and I wanted to experiment with them to see how they would play out. I think you are right that the "role dispatching" is too magic. I like it in the sense that it feels like a natural fit for concurrent processing. However, at the very least, there needs to be a way to do it explicitly as you have done. The class level casting on the other hand, I am finding very appealing. The reason being that it provides a very natural limiting structure to scope of a context, i.e. one role per attribute per context. By casting at the instance level, a context can do anything whatsoever, each method could take actions completely unrelated. But having the casting the at the class level ensures the methods will have a interrelated coherence.
From: Jörg W Mittag on 12 Feb 2010 18:57 Brian Candler wrote: > Thomas Sawyer wrote: >> http://architects.dzone.com/videos/dci-architecture-trygve > [...] > Then at the end, it says that an account isn't really an object at all - > but all the previous code has shown it as a concrete object (e.g. > Account.find(id)). So an example of what an account role *should* look > like in code would be good. I have been following DCI on and off ever since James's JAOO 2008 interview and more closely since James's and Trygve's March 2009 article. I won't even try and pretend that I understand as little as 1% of this stuff, but there is one important idea that I have carried around with me, ever since I read all those "it's just traits" comments on the Artima article: one thing that I always need to remind myself of, is that doing DCI in Ruby is like doing OO in C: it's only a *very* rough approximation which lacks much of the expressive power and often confuses the idea with the implementation. Whenever I think "it's just traits/aspects/mixins/responsibilities and why does he say this isn't an object when it clearly is?" I picture myself trying to explain OO to a C programmer, in C, and constantly answering questions like "it's just structs and function pointers and why do you keep calling it an object when it clearly is a struct?" and yelling back at him "because there are no objects in C, idiot, structs is all I have!" I believe that, like OO or logic programming, DCI is only going to start to *really* shine (or, as the case may be, bomb spectacularly) when we have DCI languages. There were many logic systems in Lisp before Prolog, and as Alan Kay recently pointed out, there were object systems in assembly going back as far as 1952, but before Prolog, Simula and Smalltalk nobody cared, and nobody understood. It's hard to see the real value of the idea behind the implementation, if the implementation leaks all over the place as structs+function pointers as objects and methods do in C and objects, classes and mixins as data, context and roles do in Ruby. Unfortunately, for this dynamic role injection stuff, we run into one of the (very few) limitations of Ruby. We cannot just, as Trygve says, "subclass the compiler" and "add to and delete methods from the method dictionary" in Ruby (although we probably *can* in Rubinius) like Trygve's Squeak implementation does or subvert the compiler like James's C++ template metaprogramming implementation does. Ironically, this stuff, which looks like a match made in heaven for Ruby, is one of the *very few* instances where C++'s static metaprogramming outshines Ruby's dynamic metaprogramming and the leaky abstraction of ECMAScript actually *helps* rather than hurts. (Although I *do* have a seed of a spark of a hunch on how to fake dynamic class composition.) Anyway, I don't really have anything useful to contribute to this discussion other than the tip that it helps to constantly remind myself that DCI in a non-DCI language is always only an approximation. jwm
From: Jörg W Mittag on 12 Feb 2010 19:30
Jörg W Mittag wrote: > [...] > I believe that, like OO or logic programming, DCI is only going to > start to *really* shine (or, as the case may be, bomb spectacularly) > when we have DCI languages. BTW: I *do* realize that this contradicts what James and Trygve have been saying, that DCI is a paradigm that enables "good OO" in *existing mainstream* languages. jwm |