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).
Related
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.
Wiithout wanting to create an open ended question....
F# is currently absent from the Windows 8 dev preview. There is a mapping layer in WinRT that wraps core objects into CLR objects for C# / VB or through other mappings for different languages.
Given that this model does not force languages through the CLR, my question as a functional programming novice is: Is this any benefit to F# (having a direct mapping to WinRT without the CLR layer could further reduce mutability, more native list types) or would it make sense to have a more purely functional language join the ecosystem and leave F# where it is (bearing in mind that interoperability is no longer restricted to CLR languages)
If anybody creates a pure functional mapping for WinRT, that would be quite interesting. However, there is no single right way of doing functional library for something (just like there is no single right way of doing object-oriented library).
The great thing about F# is that you can easily write your own functional wrapper over the underlying (imperative) API. For WinRT, this means that we can easily implement different functional approaches to WinRT programming, without having to write any COM-based mappings.
My solution is split into 3 projects. Model, Services and Web. In my Service project, I'd like to use some F# features in it. Whats the best way to use 2 separate service projects, one for C# and one for F# and how would I structure these projects?
I think that the best option would be to split your Services project into:
Main C# project (especially if it contains some designer generated code)
An implementation F# library that is built using F# and exports the important algorithms in module or as classes (with a C# friendly interface).
This way you can use C# designers (which are generally not available for F#), but implement all the complicated functionality in F#. This approach is actually quite similar to the one I recomended recently on my blog when developing ASP.NET MVC applications in F#. The main application is written in C#, but all the interesting functionality is moved to an F# library and then used from C#.
Using ILMerge tool to merge two assemblies (as mentioned in the other referenced answer) may work, but it won't give you much benefits (the C# and F# parts won't be able to mutually reference each other), so it is essentially the same as having C# project + F# library.
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.
I see parallels between MEF and Lua. Both allow you to register methods and deploy as you need. Are both MEF and Lua forms of IoC / Dependency Injection?
I'll assume you're aware of the huge differences between these technologies and focus on the question:
"Are both MEF and Lua forms of IoC /
Dependency Injection?"
Also, I'll assume you're talking about embedded Lua versus Lua as a language.
First, let's separate Dependency Injection from Inversion of Control. Fowler defined Dependency Injection as a specific form of IoC because the idea of IoC had become so common that it was no longer a distinguishing characteristic of a system. His definition includes three main types of Dependency Injection: Constructor injection, Setter injection, and Interface injection. In all three types, the idea is to inject a specific implementation of a class or interface into a class or method that needs it. This is pretty slick because it allows you to decouple the dependency and the class that uses it. As long as they follow a contract, you can edit and swap implementations of the dependency without its consumers caring or being effected.
Using this definition, I'd say MEF passes and embedded Lua fails. MEF is largely a dependency injection framework. It allows you to dynamically load and compose external classes that implement specific contracts. Lua, on the other hand, allows extension through scripting but there is very little in the way of a contract. Sure, you could provide a Lua API for your app and that's a contract of sorts, but it does nothing to ensure a true contract is honored.
IoC is broader.(Fowler,Wikipedia) The common theme is that main program flow gives up control temporarily but receives flow status updates from components that are doing the work. Common ways to accomplish this include: events, closures, and continuations.
Using this definition, MEF easily passes (control is passed to unknown components at runtime) and you can make an argument for embedded Lua as well. The main program cruises along until it needs a function defined in external script. At that point, control is delivered to the script until it's done or is interrupted.
One thing to note is that Lua isn't particularly special in this regard. You can embed Perl, Python, Tcl, and Ruby. In fact, the general definition of IoC isn't particularly useful in a modern programming environment. It's too common. Fowler says that's why he introduced Dependency Injection as a special case. In a world of GUIs, events, threads, daemons, closures, continuations, and monads, everything uses IoC. Today, when people say 'IoC', they often mean some sort of Dependency Injection.
MEF has nothing to do with Lua, and is nothing like Lua.
MEF is a framework for extending (basically, an awesome plugin framework).
Lua is a very cool scripting language.
"Both allow you to register methods and deploy as you need." That sentence applies to C, C++, C#, VB, SQL, DI Frameworks, JavaScript, General Motors, Ford, Hospitals...