I am an iOS developer trying to learn aspect oriented programming but does Swift support aspect oriented programming?
The foundation of Aspect Oriented Programming is the intercept pattern. We start with a crosscutting requirement - something that needs to occur in many parts of the application. And then using a pointcut expression, modularize it, by identifying all of the places this requirement should be applied. This is done by intercepting a method call and weaving in additional behavior. Therefore, for a language to support AOP, it must support the intercept pattern.
Now, depending on the language, method interception can be applied either at compile-time, run-time or both. Swift is an interesting case in this regard, as it supports the following kinds of method dispatch:
Static/vtable, like C++ (faster : in tests accounted for about 1.1 nano-seconds or less of method invocation time)
Messaging, like Objective-C (slower : in tests accounted for about 4.9 nano-seconds of method invocation time). Also known as dynamic dispatch or late binding.
If you extend NSObject or use the #objc decoration then messaging will be used. Otherwise Swift will revert to static/vtable method invocations.
With the static/vtable type of dispatch, only compile-time interception is possible. In the case of C++ (and Swift) this involves using a preprocessor that generates new source, prior to actual compilation. This is a somewhat cumbersome approach and takes more effort to develop the necessary tools. Although it does give the best possible performance.
With the messaging style of method invocation run-time interception is also available. In fact, Objective-C made interception so easy that there was no formal AOP framework. It might've been useful, but "raw materials" were so good no one bothered to make one. Many of Cooca's best features take advantage of Objective-C's dynamic dispatch and the ability to intercept method calls.
Summary:
Swift will support runtime AOP if you extend NSObject or use the '#objc' decoration. There are some quirks and limitations to this - Apple's guide on using KVO with Swift will point out most of them.
If you don't extend an Objective-C base or use the '#objc' decoration, then only compile-time AOP will be possible. As yet there is no such library to provide compile-time AOP. Furthermore, a disadvantage of compile-time AOP is that it only works with classes that you have the source for.
NB1: Some languages, such as Java uses a static/vtable style of method dispatch and still support runtime method interception. This is possible as they rely on virtual machine, along with a class loader, another hook-in point. In fact Java is still classed as a 'late binding' language because of this.
NB2: Its technically possible to support provide compile time weaving against compiled-to-machine-code binaries with some limitations. The first is there aren't too many tools to support this because implementation effort is high, and must be repeated per-platform. The second is that it limits the available AOP features.
Unfortunately, Swift itself has no runtime support at this time. You have to rely on Objective-C bridging.
Here's a brand new AOP library for iOS, written in Objective-C, with Swift support.
https://github.com/MO-AI/MOAspects
Only 'before advice' and 'after advice' are available, but in the most cases, it's enough to solve your problem.
Note that it may be required adding 'dynamic' keyword to your function, when the interception against pure Swift class/method doesn't work correctly.
MOAspects is superior to two most famous AOP library for Objective-C, Aspects and BlockInjection.
Aspects doesn't support class method interception and multiple hooking into methods in class hierarchy.
BlockInjection has a critical issue not to support 64-bit.
Related
I am confused about this line
Aspect-Oriented Programming and Dependency Injection are very different concepts, but there are limited cases where they fit well together.
from this website
http://www.postsharp.net/blog/post/Aspect-Oriented-Programming-vs-Dependency-Injection
I understand the advantages of DI over AOP, but why aren't they used together more often? why are there only limited cases where they fit together? Is it because of the way AOP is compiled, that makes using both difficult?
How do you define "limited cases"? I myself always use AOP and DI together.
There are basically three ways to apply AOP, which are:
Using code weaving tools such as PostSharp.
Using dynamic interception tools such as Castle Dynamic Proxy.
Using decorators.
The use of DI with code weaving tools doesn't mix and match very well, and I think that's the reason that the Postsharp site states that "there are limited cases where they fit well together". One reason it doesn't mix and match is because Dependency Injection is about loose coupling, while code weaving hard couples your code and the aspects together at compile time. From a perspective of DI, code weaving becomes an anti-pattern. In section 11.2 of our book, Mark and I make this argument very clear. In summary we state:
The aim of DI is to manage Volatile Dependencies by introducing Seams into your application. Theis enables you to centralize the composition of your object graphs inside the Composition Root.
This is the complete opposite of hat you achieve when applying compile-time weaving: is causes Volatile Dependencies to be coupled to your code at compile-time. This makes it impossible to use proper DI techniques and to safely compose complete object graphs in the application's Composition Root. It's for this reason that we say that compile-time weaving is the opposite of DI–using compile-time weaving on Volatile Dependencies is an anti-pattern. [page 355]
If you use dynamic interception, however, which means applying cross-cutting concerns at runtime by generating decorators on the fly it works great with DI and it is integrated easily with most DI libraries out there, and can be done as well when using Pure DI, which is something we demonstrate in section 11.1.
My personal preference is to use decorators. My systems are designed around a few well defined generic abstractions, and this allows me to apply cross-cutting concerns at almost all places that are important to my system. That leaves me in very rare cases with a few spots where decorators don't work very well, but this is almost always caused by design flaws. Either by my own limitations as a developer or by design flaws in the .NET framework or some other tool. One famous design flaw is the INotifyPropertyChanged interface. You might have guessed it, but in our book we describe this method in a lot of detail. We spend a complete chapter (10) on this topic.
What is DI for and what is its use case, when we have ServiceManager?
They appear to be similar since in configuration files for both zend-di and zend-servicemanager we can set up some options such as aliases and invokables.
I am trying to get a better understanding of what is happening behind the scenes with these components, and documentation did not give me enough info.
Could you please tell me what the difference is and when I should use Di instead of ServiceManager?
Zend\DI relies on magic, like reflections, to detect and inject dependencies while service manager uses user provided factories. That is main difference.
Di sort of deprecated in community in favor of SM due to complexity, debugging and performance issues.
It supposed to be good for RAD, but you need above average knowledge to use it properly.
On the other hand SM have pretty verbose and explicit wiring, you can open your code year later and easily figure out what is going on.
Zend\Di takes care of wiring your classes together, whereas with Zend\ServiceManager you have to wire things manually and write a factory closure for every class you want to instantiate.
Zend\ServiceManager is much faster since it does not rely on the slow Reflection API. On the other hand, writing closures for large applications with hundreds of classes becomes very tedious. Keeping your closures up-to-date will get trickier as your application grows.
To address this problem, I have written a Zend Framework 2 module called ZendDiCompiler. It relies on Zend\Di to scan your code and auto-generates factory code to instantiate your classes. You get the best of both components: the power of Zend\Di and the performance of Zend\ServiceManager.
I have put quite a bit of work into the documentation of ZendDiCompiler and some easy and more advanced usage examples are provided, too.
Basically the difference is as follows:
Zend\ZerviceManager = Factory driven IoC Container
Zend\Di = Autowiring IoC implementation
Zend\Di was Refactored for Version 3. Its behaviour now more solid and predictable than v2 and it is designed to integrate seamlessly into zend-servicemanager to provide auto-wiring capabilities (no more odd magic). Since it uses PHP's reflection api to resolve dependencies it is slower than a factory driven approach. Therefore version 3 comes with an AoT compiler to create a pre-resolved Injector that omits the use of Reflection. An additional benefit: The generated factories can also be used with Zend\ServiceManager directly.
There is a guide for using AoT with both components: https://zendframework.github.io/zend-di/cookbook/aot-guide/
If I'm familiar with F# events already, and I don't plan to have too much C# interop, are there significant reasons to consider using the Reactive Framework?
I think there are two main differences:
Firstly, there is a difference between the IEvent<'T> interface (and functions in the Event module) and the IObservable<'T> interface (used by functions from the Observable module and Reactive Fx). The difference has been discussed on SO earlier.
Reactive Framework is a more complex library, so it implements many combinators that are not available in F# in Observable or Event modules (although there is a open-source project that adds many of them)
The summary is, you should prefer functions from the Observable module. If it has everything you need, there is no need for Reactive Framework. If it does not, then you'll need either Reactive Framework or MiniRx (which, I believe, is sometimes more efficient too).
The F# Event module dates back to 2006, so I think Reactive Framework is clearly inspired by that, but it does not fully replace the F# functionality (mainly because it is not standard part of .NET or F# core).
I am currently working on an F# project that contains many parallel calculations. As being bound to the trimmed .Net 4 Silverlight Framework (because of the required Silverlight compatibility) I cannot use the available .Net implmenetations and may only use the Monitor object and simple locking by using the lock Keyword.
Do you have any idea how a Shared-Exclusive lock implementation for F# might be desigend best?
I did some functional programming before but haven't concentrated on doing that parallel stuff (yet).
I'm not quite sure what exactly you need - if you need standard mutual exclusion, then the lock function is available in the Silverlight version of F# runtime.
If you need something more complex (such as multiple readers, single writer), then you can rewrite your code to use F# agents and solve the problem more elegantly. If you can add more details about the higher-level structure of your code, then someone can post an example how to solve your particular problem.
Anyway, the following SO answer shows how to write a reusable agent for multiple readers/single writer:
Implement CCR Interleave Arbiter in F#
As mentioned in the comment, you should probably try to avoid writing locks and low-level synchronization primitives explicitly, as this is a source of infinite number of bugs. F# agents give you a higher-level abstraction that is easier to use.
Theres an excellent chapter on this in Expert F# 2.0, Chapter 13 Reactive, Asynchronous, and Parallel Programming.
See example 13.13 shows a nice Request gate, something similar may be of use.
Is it possible to do Aspect Oriented Programming in Delphi? I would be interested in native support as well as third party solutions.
I don't have a specific problem I want to solve with AOP, but am simply interested in studying AOP.
AOP depends on two things:
The ability to inject additional code into an existing unit of code
A mechanism to place conditions on where code should be injected.
This is commonly referred to as code weaving. It is a specialization within the larger study of program transformation.
JIT compiled languages have more options for implementing code weaving than statically compiled programs because more information is retained in the bytecode/IL. They also support reflection, which offers the ability to manipulate code at runtime.
Delphi.NET and Prism have the same access to these capabilities as any other .NET language.
There are two AOP frameworks for Delphi Win32 that I'm aware of. The first is MeAOP, which has already been mentioned. The second is Infra. Both projects take a similar approach to AOP. They use a combination of RTTI and clever pointer manipulation to intercept method calls so you can run additional code before or after the method call. You define your cross-cutting feature as a subclass of the framework's AOP class. You register the methods you want intercepted by passing the method name as a string argument to the AOP framework.
Both frameworks are still actively developed and are actually larger in scope than just AOP. Unfortunately documentation is somewhat sparse (and in Infra's case mostly in Portuguese)
Another project attempted AOP through source code weaving back in 2004 with some success. Basically they built an aspect weaver on top of a general purpose program transformation tool called DMS and used it to inject code into delphi source files prior to compilation. Their aspect oriented language was primarily influenced by AspectJ.
http://www.gray-area.org/Research/GenAWeave/ has links to the original paper and presentation as well as some videos of the transformation process.
It may also be possible to use runtime code instrumentation to accomplish this as well. Its a technique used by some profilers to inject counters and stack traces into running code without modifying the original source. A similar technique could be used to inject crosscutting concerns into a statically compiled executable. The PinTool project is a good example of this.
ClassHelpers in the later versions of Delphi allow some very limited level of AOP type behavior. You can use ClassHelpers to inject behavior into other classes without descending from them. It allows overriding existing methods and then optionally calling that existing method.
The limitation is you must declare a ClassHelper for a specific class and it descendants. Additionally a class can only have one ClassHelper.
These are similar to Extension methods in C#.
The DSharp library features AOP:
https://bitbucket.org/sglienke/dsharp
More info can be found at: https://bitbucket.org/sglienke/dsharp
Also have a look at TVirtualMethodInterceptor.
It's in the RTL since Delphi 2010 and allows you to do OnBefore, OnAfter, etc. calls on all virtual methods on a class.
This call alone should cover must of what you need using Rtti, not weaving which is much faster than run-time weaving.