Thomas Sawyer wrote:

> I just finished watching the 2nd video. I agree with you. Coplien does
> an awful job of explaining things. Trygve, despite his age, does a
> much better job.

Thomas, I apologize if I did not explain things well for you. To move 
things forward as a community, it's good to ask questions. I'm happy to 
try to answer. Thomas, I tell people all the time that if they fail to 
ask their business people for clarification about requirements but 
instead cast cowardly aspersions supposedly out of earshot, that it 
explains many of the problems their firms have been having in its 
developments. Maybe you behave that way with your business people, but 
I'd appreciate enough respect from you to address your concerns about 
me, to me.

>> 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 don't know what he is talking about.

Yes, it is clear that you don't understand what I am talking about.

> It's as if he thinks, if
> something isn't solid it isn't an object.

No, that isn't it. Instead of guessing, or putting words in my mouth, or 
assuming, you could have asked me. I'm pretty easy to find on the web. I 
have done my best in the above posting to answer your question. I do so 
as a service and because I think it's important that this community 
understand the subtleties here.

> And his whole speel about
> logging-in is not a usecase because there's no business goal, is silly
> too.

This represents a fundamental misunderstanding of use cases. The 
distinction between atomic operations on objects (the direct 
manipulation metaphor) and the role of algorithms (the use case angle) 
is fundamental to understanding why DCI is different from 
object-oriented programming. I use the term "use case" in the Cockburn 
sense, as a collection of possible scenarios. Each scenario is a 
collection of interactions towards a goal. I think this definition is 
consistent with Jacbosson's more formalized use case framework. I am not 
sure what you are using as your reference standard, but I would be 
interested in your arguments against Cockburn's use of the goal as a 
major element that distinguishes use cases from just blah blah blah. 
Words mean things, and use case is not just Swedish for scenario.

> He's splitting hairs over words and as much as he thinks DCI is
> so cool, I'm not sure he actually "gets it" himself.

Can you translate that into some delineated professional feedback?

> However, at the
> very beginning he does point out the main point of the whole pursuit
> -- code readability.
> 
> His Ruby code, btw, wasn't very well written, would not run and worse,
> I don't think represents DCI well either. 

Well, my version of the code runs fine here. One takes certain liberties 
with presentation in PowerPoint to a large audience to make points about 
design. And the code passes Trygve's muster as representing DCI well; we 
had been corresponding intensely to nurture the ideas using this 
example. But it is good to hear your input. Maybe we have found someone 
here in Thomas who understands DCI better than Trygve and I do. Please 
join the object-composition list, listen, learn, and contribute 
positively. When you post objections in a frustrated way on this list 
without engaging those you criticize, it makes me frustrated, and it 
does not advance our collective understanding.

If you feel the Ruby style bears improvement I am open to suggestions.

> (P.S. I also think this is much more like AOP then Coplien is willing
> to admit.)

Second, I'd like to know why; and first, I'd like to know why it's 
important. Again, I think you are making the mistake that another poster 
here warns about: confusing the language mechanisms with the design 
ideas.

These things just take time. Keep working at it, guys, and don't let 
your preconceptions get in the way... any more.
-- 
Posted via http://www.ruby-forum.com/.