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.
  • This distinction lies at the heart of aspect oriented programming, where the idea is that using declarative decorations you can add additional aspects without introducing the cross cutting concerns into the main flow (herein referred to as the "natural" code).

    The general idea is that if the natural code is well factored then it is easy to use a hook based system to do things like passing around shadow parameters, wrapping with hooks, adding validation, etc.

    AOP calls the "synthetic" code "advice". Advice is

    • by Ovid (2709) on 2009.10.12 10:39 (#70854) Homepage Journal

      From what I've read about AOP, for the developer to truly understand it, he/she needs proper tool support external to the language (such as the AspectJ integration in Eclipse). This seems wrong to me. Defining advice in a file and having that silently alter the behavior of other classes is classic action at a distance. An unknowing developer might change the name of a method, thus eliminating the join point. This seems to be a constant criticism of AOP that I read about.

      Join points, from what I see, alter methods found with match the join point pattern, but if that pattern is not there, it's a silent failure. A role's requirements not being met, however, are a composition-time failure.

      With roles, you have to do a bit more work to explicitly add the role to the affected classes, but by being explicit, you can gain the advantages of AOP without less mysterious "action at a distance".

      So, what am I misunderstanding? :)

      • Defining advice in a file and having that silently alter the behavior of other classes is classic action at a distance.

        Welcome to Java, where the solution to "This language is insufficiently dynamic!" is "Get a better IDE that lets you manage external XML files to inject reflection-compiled code at startup time!"

        • I've been using Eclipse lately and I think it has some great features (not all of which can be added to Perl), but I suspect it and similar IDEs are becoming so much of a crutch that some really stupid ideas are becoming popular with it.

          • There's a language design question.

            How much can or should your tooling or community standards or patterns of usage make up for deficiencies of abstraction in your language?

            The Java language and ecosystem have answered that question based on fundamental design goals of the Java ecosystem (backwards compatibility in the VM trumps almost everything else).

            Likewise, I suspect the real reason Mono exists is as much tooling as it is anything else.

      • I was just commenting that the goals are similar to those of AOP, and that it might be worth to have a look at the prior art in that field.

        Whether or not an IDE is necessary to use AOP is irrelevant. I've never used AOP (apart from playing with the Aspect module), but it was definitely interesting to learn why AOP is defined the way it is.

        Your usage of roles in this case and AOP are very different implementations of a similar idea (that there are two "types" of code).

        FWIW, Moose's method modifiers and their

        • Your usage of roles in this case and AOP are very different implementations of a similar idea (that there are two "types" of code).

          AOP was an inspiration for roles. This is why the phrase "cross-cutting concerns" appears in so many early discussions of what would become roles.