in reply to Re: Re^4: Aspect-Oriented Programming: Couple of Short Examples
in thread Aspect-Oriented Programming: Couple of Short Examples

I would look at AOP slightly differently, at least from a Perl point of view. It allows you to inject a bunch of arbitrary opcodes at any defined point in the optree. Consider them more like database triggers. "When [OPCODES], then [MY STUFF]." So, you could have:

Right now, we would do this using source filters, similar to what adrianh has done. But, the "Real Way" would be to provide opcode-filters. I'm not sure if Perl6 will seamlessly provide for this, or not. You will be able to do it in Perl6, though, because you will have access to the optree, even if it's after the compile step.

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re6: Aspect-Oriented Programming: Couple of Short Examples
by kelan (Deacon) on Aug 05, 2003 at 20:46 UTC

    I believe Perl6 will provide for this seamlessly with wrappers. From what I understand, you'll be able to wrap a function call with any arbitrary code and henceforth (in the scope the wrapper lives in?) any call to that function will actually call the wrapper, which can do anything you want. See the .wrap subsection of Apocalypse 6, which even specifically mentions Aspect Oriented Programming.

    kelan

    Perl6 Grammar Student

[reply]
Re^7: Aspect-Oriented Programming: Couple of Short Examples
by adrianh (Chancellor) on Aug 06, 2003 at 11:05 UTC
    I would look at AOP slightly differently, at least from a Perl point of view. It allows you to inject a bunch of arbitrary opcodes at any defined point in the optree.

    This is all "how" not "why". This isn't describing AOP - it's describing a way AOP can be implemented. You could equally be talking about a method for implementing pre-conditions, post-conditions and class invariance in a design by contract system ;-)

    Right now, we would do this using source filters, similar to what adrianh has done.

    I haven't done anything with source filters - I mostly think they're evil ;-)

[reply]
      What's the difference? As far as I'm concerned, AOP allows me to create pre- and post-conditions, as does design-by-contract. At some point, the rubber's got to hit the road and, if the 'how' is the same, who cares?

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]

        It matters because the "how" and the "why" are different.

        AOP is not the ability "inject a bunch of arbitrary opcodes at any defined point in the optree". Neither is it just the ability to add pre- and post-conditions to a subroutine.

        You can have AOP without opcode insertion (e.g. via wrapping subroutines in Perl's Aspect or AspectR in Ruby.

        You can have opcode insertion without something being AOP - many macro systems for example.

        You can have pre- and post- conditions without something being AOP (e.g. Class::Contract does not allow you to do AOP).

        AOP is about creating "aspects" that describe functionality that cross-cuts a traditional OO class hierarchy.

        If you're interested you might find some of the early Parc papers useful (Aspect-Oriented Programming and RG: A Case-Study For Aspect-Oriented Programming).

[reply]

In Section Meditations