Aspect oriented programming: Difference between revisions
Rename Perl 6 -> Raku, alphabetize, minor clean-up
Thundergnat (talk | contribs) (Rename Perl 6 -> Raku, alphabetize, minor clean-up) |
|||
Line 120:
Bemson's [https://github.com/bemson/Flow/wiki/ Flow library] introduces an aspect-like framework for JavaScript.
=={{header|Julia}}==
Line 159 ⟶ 158:
There is no way to debug machine code (we can write and execute machine code in memory buffers for Code, which code can't be altered, we use for data only another buffer(s))
=={{header|Perl}}==
The CPAN module <code>Aspect</code> brings features of AOP to Perl. From the documention:
Line 174 ⟶ 173:
This allows the Perl implementation of Aspect-Oriented Programming to be stateful and adaptive in a way that Java cannot (although the added power can come with a significant speed cost if not used carefully).
=={{header|Perl 6}}==▼
All methods in Perl 6 are really just routines under the control of the meta-object protocol for purposes of dispatch, so there are several ways to subvert the system in order to deal with aspects. First, you could intercept the MOP calls, or you could install alternate metaclasses. More likely, since methods are really just routines in disguise, and since a routine can be wrapped (in place) in an outer routine via the <tt>.wrap</tt> method, you'd just wrap all the methods and other routines that share a cross-cutting concern.▼
Note that the optimizer is free to assume routines are immutable after CHECK time (the end of compilation), so while you can always wrap routines during compile time, you might need a "<tt>use soft</tt>" declaration or some such to enable wrapping at run time, that is, in order to keep considering the routine to be mutable. (Only code doing the Routine role is ever mutable in Perl 6—bare blocks and other lambdas are considered immutable from the start.) Note that keeping routines mutable is likely to pessimize spots where the optimizer might otherwise be able to inline the code.▼
Of course, you can also simply redefine Perl 6 on the fly to be any language you want in the current lexical scope, so you are really only limited by your imagination in how you wish to express these "aspects", whatever you might mean by that term…▼
=={{header|Phix}}==
Line 218 ⟶ 209:
=={{header|Python}}==
Python has special syntax for [http://legacy.python.org/dev/peps/pep-0318/ decorators] acting on functions and methods, as well as [http://stackoverflow.com/questions/100003/what-is-a-metaclass-in-python metaclasses].
(formerly Perl 6)
▲All methods in Perl 6 are really just routines under the control of the meta-object protocol for purposes of dispatch, so there are several ways to subvert the system in order to deal with aspects. First, you could intercept the MOP calls, or you could install alternate metaclasses. More likely, since methods are really just routines in disguise, and since a routine can be wrapped (in place) in an outer routine via the <tt>.wrap</tt> method, you'd just wrap all the methods and other routines that share a cross-cutting concern.
▲Note that the optimizer is free to assume routines are immutable after CHECK time (the end of compilation), so while you can always wrap routines during compile time, you might need a "<tt>use soft</tt>" declaration or some such to enable wrapping at run time, that is, in order to keep considering the routine to be mutable. (Only code doing the Routine role is ever mutable in Perl 6—bare blocks and other lambdas are considered immutable from the start.) Note that keeping routines mutable is likely to pessimize spots where the optimizer might otherwise be able to inline the code.
▲Of course, you can also simply redefine Perl 6 on the fly to be any language you want in the current lexical scope, so you are really only limited by your imagination in how you wish to express these "aspects", whatever you might mean by that term…
=={{header|Scala}}==
Jones Bonér introduces AOP for Scala in [http://jonasboner.com/aop-style-mixin-composition-stacks-in-scala/ this blog].
=={{header|Tcl}}==
Tcl's <code>trace</code> command enables much AOP-like functionality, with variable traces allowing interception of accesses to variables, and command traces allowing interception of executions of procedures, etc. In addition, TclOO (Tcl's <!--main--> object system) also supports filter methods, which wrap around invocations of methods of an object (or all methods of a class) as a generalisation of before, after and around advice. This works well when combined with a mixin, allowing interception to be applied on a per-instance basis if desired.
| |||