Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... I'm still not totall clear about this roles nonsense :-) :-)

    • I knew someone would bring that up :)

      Roles are shared behavior with methods which can't conflict. It's tough to get any simpler than that.

      • I'm partially kidding :-)

        I don't really buy your law though. It was tough for me to "get" roles for various reasons. It was tough for me to get declarative Prolog-ish languages when I first encountered them. I know a bunch of people who took a hell of a time to understand OO. I know a bunch of folk who don't really "get" TDD, XP or Scrum.

        Yes - there are nice sound bites for all of them. But they don't really "explain". The concepts are often deep - even if they have a simple container.

        • by Ovid (2709) on 2009.10.02 6:08 (#70751) Homepage Journal

          The actual law should read (and I knew this when I posted my rather hyperbolic comment): "the more difficult it is to explain a technology which aims to "improve" software, the more likely it is that that this technology fails in its goals. Not quite as catchy, though :)

          See Aspect-oriented programming [wikipedia.org] for a great example. What's a "pointcut"? What's a "join point"? What's "advice"? Why is "advice" described as "additional behavior"? "Advice", to me, reads "optional behavior". And does AOP require special IDEs to properly handle it or not? It's issues like this which make it hard to grok and limits its adoption.

          Roles appear to solve the problems which AOP attempts to solve by separating responsibility from behavior. Yes, they are hard to explain to people who have been trained in traditional OOP, but they are very, very easy to use.

          • Aspect-oriented programming is used to concisely implement cross-cutting concerns across a high number of classes and methods that would otherwise require immense quantities of hard-to-maintain code spread out over your whole application.

            Examples of cross-cutting concerns which are very amenable to Aspect techniques include logging, debugging and performance monitoring.

            • So what's a "pointcut"? What's a "join point"? Do you really need a custom IDE to use AOP or not? (I've heard both ways)