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