[12] closure in java^c#

I feel c# Action<T1, T2 ..> and Func<T1,….> constructs are a good illustration of closure. The code block has access to local variables in the enclosing block. Static/non-static Fields are accessible too.

I feel the c# syntax is much simpler than java. http://stackoverflow.com/questions/5443510/closure-in-java-7  said “Since Java 1.1, anonymous inner class have provided this facility in a highly verbose manner. they also have a restriction of only being able to access final (and definitely assigned) variables.”

A practical scenario — When I extract common code into a static (sometimes non-static) utility function, I often end up passing in billions of local variables. It often pays to refactor the function into a closures. (More verbose in java but technically doable.) With closures you don’t need to pass those variables as they are implicitly passed into the closure (or needs no passing at all).

Obviously, if the common code is complicated (above 10 lines) the closure would look bulky. Solution?  Keep the static utility function as is when you refactor, and have the closure call it. Suppose the static function compute() takes 5 local variable arguments. Closure can be invoked with none but closure will invoke compute() with the 5 local variables “implicitly passed in”.

java8 lambda under the hood #phrasebook

Q: how are java8 lambda expressions translated?

* Special helper method – InvokeDynamic. You can see it in the bytecode
* Static methods – a non-capturing (stateless) lambda expression is simply converted to a static method
* a capturing lambda expression can also become a static method with the captures as additional method args. This may not be the actual compiler action, but it is a proven model. (Compare : separate chaining is one proven implementation of hash tables.)

However, static methods obscure an essential rule — the lambda expression’s type must “look like” a subtype of a SAM interface. Remember you often pass a lambda around as if it’s a SAM implementation instance.

So even if the actual work (like number crunching) is done in a static method, there must be some non-static wrapper method in a SAM subtype instance.

https://blog.codefx.org/java/dev/lambdas-java-peek-hood/ has some details on the evolution and design.

*morePure* SAM^functional interface]java

Most experts and authors on the internet don’t differentiate the 2. [[functional thinking]] says that a java 8 functional interface can have default methods in addition to a SAM (single abstract method)

Later, I will probably add a bit more details, but this is the key message.

Q: is a lambda related to SAM or FI (with default methods)? Official answer seems to be FI but can a FI-with-default-methods?

delegate: Yamaha makes motorbikes + pianos

label: lambda/delegate
when we say “delegate” we should but don't make an explicit distinction between a delegate typename vs a delegate instance.
Also, we seldom make an explicit distinction between the multicast delegate and unicast delegate usages, but these 2 have too little overlap to be discussed as the same concept. 
Yamaha makes motorbikes + pianos

lambda – final local var — rationales, loopholes

Possibly a popular interview question…..

For Both lambda and inner classes to use a given variable:

A) local vars in enclosing method must be (as of Java 8, "effectively") final
** subversion / loophole — a final local variable in the form of "array of 1" would let the lambda to modify the content
**** similarly, you can provide a wrapper object, who is a final local variable but not immutable.
B) enclosing Class instance fields don’t need finality to be usable in lambda.

The most important motivation for the (effective) finality restriction is thread safety. For (B), this restriction is impractical.

Incidentally (perhaps another post), in java 8, you lambda is compiled not as an inner class, but as a static method with a special helper class.

c# delegates – 2 fundamental categories

Update: java 8 lambda. [[mastering lambds]] P 5 mentions AA BB DD as use cases for Command pattern

AA — is the main topic of the book
BB — https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html
DD — http://www.oracle.com/technetwork/articles/java/lambda-1984522.html and http://www.drdobbs.com/jvm/jdk-getting-a-head-start-with-lambdas/240008174

Today I finally feel ready to summarize the 2 usage categories of c# delegates. If you are new like me, it’s better to treat them as 2 unrelated constructs. Between them, the underlying technical similarities are relevant only during initial deep dive, and become less important as you see them in various patterns (or “designs”).

In java, these features are probably achieved using interface + other constructs. Dotnet supports interfaces too, but in some contexts offers more “specialized” constructs in the form of delegates. As shown below, in such a context interfaces are usable but less than delegates.

Most tutorials would start with unicast delegate, without the inv list.

Coming from a java or c++ background, you will want to find a counterpart or close equivalent to delegates. Almost hopeless for BB. For AA there are quite a few, which adds to the confusion.

AA) lambda as function AAArgument
* I believe compiler converts such a lambda into a STATIC method (there’s really no host object) then bind it to a delegate Instance
* often returns something
* Usually _stateless_, usually without captured variables.
* predominantly unicast
* Action, Func and Predicate are often used in this context, but you can also use these 3 constructs as closures, which is a 3rd category beyond AA and BB
* Domain? Linq; functor argument as per Rajesh of OC
* Before java 8, often implemented as an interface or an anonymous inner class

BB) event field Backed by a multicast delegate instance (See other posts on “newsletter”)
* Usually NON-STATIC methods, esp. in GUI context
* Usually returns void
* A callback method is usually _stateful_, because the callback method often does its job with “self-owned” i.e. this.someField objects, beyond the argument objects passed in
* event is a pseudo _f i e l d_ in a class. Static field or non-static field are both common.
* Domain? GUI + asynchronous WCF
* we must register the callback method with the event source.
** can lead to memory leak
* in java, implemented by several callback Objects supporting a common interface (cf swing)

Some of the other categories —
CC) CCClosure — stateful, seldom passed in as a func arg
DD) thread start
EE) Passing in a delegate instance as a function input is the lambda usage (AA). How about returning from a function? P83 [[c#precisely]] shows examples to return an anon delegate instance. This is an advanced and non-trivial unicast use case. The underlying anon method is usually static and stateless

In a source code with AA, we see lots of custom delegate Types created on the fly.

In a source code with BB, delegate Instances take center stage, since each instance is assigned to a … pseudo field. The delegate type is less complicated.

lambda meets template

In cpp, java and c#, The worst part of lambda is the integration with (parametrized) templates.

In each case, We need to understand the base technology and how that integrates with templates, otherwise you will be lost. The base technologies are (see post on “lambda – replicable”)
– delegate
– anon nested class
– functor

Syntax is bad but not the worst. Don’t get bogged down there.

lambda is more industry-standard than delegate

Before java and c++ introduced lambada, I thought delegate is the foundation of lambdas.

Now I think lambda is an industry standard, implemented differently in c++ and java. See post on “lambda – replicable”. For python…

Bear in mind
A) the most fundamental, and pure definition of lambda — a function as rvalue, to be passed in as argument to other functions.

B1) the most common usage is sequence processing in c#, java and c++
* c# introduced lambda along with linq
* java introduced lambda along with streams

B2) 2nd common usage is event handler including GUI.

See post on “2 fundamental categories”

c++ parametrized functor – more learning notes

Parametrized Functor (class template) is a standard, recommended construct in c++, with no counterpart in java. C# delegae is conceptually simpler but internally more complex IMO, and represents a big upgrade from c++ functor. Better get some clarity with functor before comparing with delegates.

The most common functor is the simple stateless functor (like a simple lambda). The 2nd common category is the (stateful but) immutable functor. In all cases, the functor is designed for pass-by-value (not by ref or by pointer), cheap to copy, cheap to construct. I see many textbook code samples creating throwaway functor instances.

Example of the 2nd category – P127[[essentialC++]].

A) One mental block is using a simple functor Class as a template type param. This is different from java/c#

B) One mental block is a simple parametrized functor i.e. class template. C++ parametrized functor can take various type params, more “promiscuous” than c#/java.

C) A bigger mental block, combining A+B, is a functor parametrized with another functor Class as a template param. See P186[[EssentialC++]].

This is presented as a simple construct, with about 20 lines of code, but the more I look at it, the more strange it feels. I think this is somwehwat powerful but unpopular and unfamiliar to mainstream developers.

Functional programming in c++?

In java, we write a custom comparitor class rather than a comparitor class Template. We also have the simpler alternative of a Comparable interface, but that’s not very relevant in this discussion. Java 8 lambda — http://www.dreamsyssoft.com/java-8-lambda-tutorial/comparator-tutorial.php

immutability of a c# delegate instance

Mutability is all about object state. We are familiar with object state of ordinary objects, but delegate objects are different – subtle.

A delegate’s object state is its inv list. More specifically, the state is the ordered list of 2-pointer thingies.

So immutability means that the collection and ordering are permanent. Each 2-pointer thingy is naturally immutable given that object pointer [1] and the function pointer are just addresses rather than “pointer variables”. In other words, each 2-pointer thingy holds 2 addresses and there’s no way to “edit” any address.

Immutability doesn’t cover the Target object. Target object is fully mutable. This is what confuses folks like me. If an immutable Student object HAS-A professor field, then the professor pointee object is presented as immutable. Here’s the key — Every time a Student method returns the professor, the professor is cloned, so the original professor instance is never exposed/leaked. No such cloning underlies the immutable delegate instance.

[1] This is actually the Target property of the dlg instance. For a static method, Target is null.

c#multicast event field=newsletterTitle=M:1 relationship

This is a revisit to the “BB” in the post on two “unrelated” categories of delegate —

BB) event field Backed by a multicast delegate instance

If a class defines 2 events (let’s assume non-static), we can think of them as 2 newsletter titles both owned by each class Instance. Say Xbox newsletter has 33 subscribers, and WeightWatcher newsletter has 11 subscribers. If we have 10 classes instances, theen 440 subscriptions.

In general, Each newsletter title (i.e. event field) has
* exactly 1 owner/broadcaster i.e. the class instance
* 0 or more subscribers, each a 2-pointer wrapper, as described in other posts on delegates.

You can say each newsletter title (i.e. each event field) defines a M:1 relationship.

Forgive me for repeating the obvious — don’t confuse an event Field vs an event Firing. The Xbox newsletter can have 12 issues (12 event firings) a year, but it’s all under one newsletter title.

invoking a delegate instance – explict Invoke()

Most c# folks take the shortcut by writing “this.myDelegateInstance();”. But this sugar-coated syntax masks off the distinction between a method and a delegate. C# syntax sugar coating trivializes this distinction because c# “wants” you to treat delegate instances as if it’s a method defined nearby. However, sometimes I want the distinction highlighted.

When the morphing hurts (in high-complexity codebase), I prefer the long-winded syntax myDelegateInstance.Invoke()

This kinda small tweaks can add up to a more readable codebase.

transformer blackboxes in linq

A lambda used in Linq is often a transformer function, or a converter or lookup or mapper or translator function.  All of these words describe the same generic blackbox having exactly 1 input object and 1 output object.

The 1 input object is carried by the range variable in Linq. Output can be a field of the input. Output can be another object (perhaps of anonymous class). Output can be a true/false flag…

Many Linq sequence operations “Apply a Transformer On” the input sequence.
eg: Where() applies a filtering transformer on the input sequence
eg: OrderBy() applies a sorter transformer on the input sequence
eg: Select() applies a one-to-one mapping transformer from input sequence to an output sequence

— OrderBy() —
Comparitor.java takes *2* arguments and returns a comparison result. Ditto for comparitor in STL sort(). Linq OrderBy() is a bold departure.

OrderBy() looks more like SQL order-by, specifying a sorting “key-field”.

This is the Hollywood principal like spring RowMapper. Inernally, the sorter (“the Hollywood”) will pick 2 elements from the sequence and compare that key-field to decide who wins….(imprecise language, admittedly). The only info needed by Hollywood is “which (pseudo) field to use for Ranking items”. A crude example — You can rank companies by reputation, by popularity, by profit … OrderBy() answers that question.

Therefore OrderBy accepts a transformer blackbox with 1 input i.e. the range var , and 1 output i.e. a “key” pseudo-field. Actually the field can be any value computed from fields of the input object.

SAM interface^lambda, across 3 languages

(In this discussion I suppose it’s probably OK to ignore the multicast feature of delegates.)

update — see java lambda and Single-Abstract-Method interface on http://www.oracle.com/technetwork/articles/java/lambda-1984522.html

I used to feel a (unicast) delegate TYPE is quite similar to a SAM interface. Now I doubt it.

C++ has abstract classes. When all the methods are pure virtual, that’s an interface (as in java). In this tradition, an interface is typically implemented by a Stateful class. Most textbooks and most schools introduce interface of this kind. What if the implementation class is stateless?

(To keep things simple let’s suppose there’s just 1 method.)  Then the objects needed by the method must be passed in. This feels like a static utility method without the static keyword. Such an interface is quite a different animal from the traditional interface. A non-capturing Lambda is the best example. But also
– static nested classes in java
– anonymous delegates

Where c# API uses a lambda, java often uses a SAM interface, since Java didn’t support lambda until Java 8.

I feel in both c# and c++, lambda is often used as a function argument (not “parameter”). Imagine you have a method parameter whose type is an SAM interface,
– and this interface has just 1 (or few) implementation(s)
– and the instance of this implementation class is basically stateless,

then this SAM parameter is probably a lambda trapped in an SAM. C# 3.0 and c++11 would set it free.

c#delegate instance HAS-A inv list@@

Everything important to a delegate instance is in its inv list, but technically, is there something else in a delegate instance?

Compiler provide no way to modify an inv list. Immutability is guaranteed by the compiler. I feel immutability simplifies physical layout. I feel a simple implementation would be a thin wrapper over the inv list. The simplest implementation could be nothing but the inv list. A delegate instance is an object on heap. The inv list is also an object on heap.

Note Delegate.Remove() is a global static method which automatically returns null when it would otherwise produce an empty inv list. Nature abhors a vacuum; c# abhors an empty inv list.

More about the immutability – see other posts.

Multicast delegate in c# (+AWT), briefly

cf swing AWTEventMulticaster …
All c# delegate types are multicast. The word “multicast” is /superfluous/redundant/, just like Reentrant in ReentrantLock. You can similarly say silly things like “Secure SSL”, or “Reliable TCP”.

According to http://msdn.microsoft.com/en-us/library/system.multicastdelegate.aspx, a MulticastDelegate has a linked list of delegates, known as an invocation list. When a multicast delegate is invoked, the delegates in the invocation list are called _synchronously_ in the order in which they appear.

http://blogs.msdn.com/b/brada/archive/2004/02/05/68415.aspx says ” We abandoned the distinction between Delegate and MulticastDelegate towards the end of V1.” Even though MulticastDelegate type extend Delegate type, system will not even allow you to derive from Delegate directly. Instead, all delegates extend MulticastDelegate.

delegate instance is passed by value@@

myEvent += myDelegate;

Q: Is myDelegate passed by reference?
A: No. member-wise copying. In other words, each item in the delegate inv list is passed in (by reference?).
A: No. The invocation list (say 2 callbacks) are appended to myEvent’s internal inv list, and new list is ReBound to myEvent internal delegate variable.

That’s a short answer. For the long answer, we need to forget events and callbacks and focus on pure delegates as list objects holding simple “items”. Suppose dlg1 variable points to address1, and dlg2 points to address2.

dlg1 += dlg2 // translates to
dlg1 = Delegate.Combine(dlg1, dlg2). // Note: re-binding dlg1

Now dlg1 points to newly allocated address11. At this address there’s a new-born delegate object whose inv list is

[item1 at addr1,
item2 at addr1 …
itemN at addr1,
item1 at addr2,
item2 at addr2, ….
itemM at addr2]

According to http://msdn.microsoft.com/en-us/library/30cyx32c.aspx, some of the items could be duplicates — Legal.

30 seconds after the Combine() operation, suppose dlg2 is subsequently modified (actually re-bound). Instead of 2 callbacks at addr2, variable dlg2 [1] now points to addr22 with 5 callbacks. However, this modification doesn’t affect the inv list at addr11, which dlg1 now points to.

Therefore, we can safely say that in a Combine() operation the RHS delegate’s inv list is copied-over, passed by value or “pbclone”.

[1] like all java reference variables, a c# delegate variable is a 32-bit pointer object. As explained in
http://bigblog.tanbin.com/2012/03/3-meanings-of-pointer-tip-on-delete.html, the compiler is likely to allocate 32 bit of heap for this 32-bit object.

c#static class2call instance method@any object

Update — I wonder how C programmers could solve this problem. I guess we would just use pointers + optionally some simple TMP tricks. The static class would have a pointer-container to hold listeners. No complexity about event or delegates.

“Static utility class should never know about the listeners” now looks like a doctrine introducing artificial complexity.

Context — you have a (shared) utility static class freely usable from anywhere, but this utility class should not “know about” the client classes using it.  It does know how to call some public WCF query service, and subsequently a static[1] callback method handles data received.

[1] in a c# static class, all methods are static, as far as I know.

Now suppose some Student1 object is interested in the query result and would like to receive a callback. Here’s a naïve/non-ideal solution — Student class to define a method that also invokes the WCF query and privately handles data received. Student1 to use this new method…. Code duplication.

Another non-ideal solution — the static class’s callback method to invoke an instance method on Student1. But then the utility class should NOT hold a reference to Student1!

My Solution – utility static class to expose a static event whose data type is a dummy void-void delegate

public delegate void Dlg1();
public static event Dlg1 SnapshotsReceived;
private static void TheCallback()
SnapshotsReceived(); // fire event

Now our Student1 object can register interest in SnapshotReceived, by passing Student1’s address into the utility static class. Under the hood, static class has a hidden static inv list, each link node holding a 2-pointer thingy. The Student1 reference is in the inv list.

unicast delegate -> anon -> lambda

http://msdn.microsoft.com/en-us/library/bb882516.aspx is concise about the “evolution” of the inline-delegate Technique. Note I call it a “technique” because this is nothing but syntactic sugar. All the different alternative code techniques therein translate to the earliest version. It’s extremely important to know what goes on behind the scene, and that means the earliest, base version.

From the evolution, you can tell that the c# creators intended lambda to be a Wrapper over unicast delegate. In other words, there’s always a unicast delegate instance behind every lambda.

For a bigger picture of delegates, see my post on 2 fundamental categories.

LINQ predicate delegate ^ boolean functors in STL

http://stackoverflow.com/questions/191153/when-would-you-use-delegates-in-c shows a nice usage of delegate —

One such (functional programing) technique is to use them for filtering sequences of data. In this instance you would use a predicate delegate which accepts one argument and returns true or false depending on the implementation of the delegate itself.

using System;
using System.Linq;
using System.Collections.Generic;
class Program{
  static void Main() {
        List names = new List {
                "Nicole Hare",
                "Michael Hare",
                "Joe Hare",
                "Sammy Hare",
                "George Washington",
        // Here I am passing "inMyFamily" to the "Where" extension method
        // on my List.  The C# compiler automatically creates
        // a delegate instance for me.
        IEnumerable myFamily = names.Where(inMyFamily);
        foreach (String name in myFamily)
    static Boolean inMyFamily(String name){ // unary boolean functor
        return name.EndsWith("Hare");

an event pseudo-field = wrapper over a delegate field

Summary — an event pseudo field is a bunch [1] of callbacks registered (with the host object) to be notified/invoked.

Each callback is a 2-pointer thingy — an enhanced functor known as a delegate instance. First pointer references the “receiver object”.

[1] an ordered list

Suppose an instance of class Thermometer has a bunch of callback listener Objects each registered with this thermometer. When a new temperature is produced, all these listeners are invoked when runtime executes MyEvent(…args). That’s the requirement. C# does it with event pseudo-fields.

Under the hood, this thermometer has a delegate Object enclosing an invocation list. Each node on the list holds 2 pointers to a) the (non-static[1]) method and also to b) the object to call on. Good solution, so what’s the “event” field?

Answer — the event pseudo-field is a wrapper over the hidden delegate field. Like a property pseudo-field, an event defines a pair of add/remove methods. In the case of add(), “myEvent += d1” simply calls “_hiddenDlgField += d1″

http://www.yoda.arachsys.com/csharp/events.html explains why exposing the delegate field is a bad idea.

[1] This is the most common usage of delegate. Alternatively you can also register a static method as a callback.

the base Delegate class isn’t a delegate type

Q: Why is the base Enum class not a enum type?
I feel an instance of this particular class has no integer representation, unlike an enum instance.

Q: Why is the ValueType class not a value type?
I feel this class exists to provide a suitable Equals() and GetHashCode() suitable for most structs. I feel this is like an empty abstract class. I feel it has no field, so copying a ValueType instance should not be a copy by value.

Q: why is the Delegate class not a delegate type?
I feel this type doesn’t specify a method signature and doesn’t have an inv list

Func/Action – 2 super delegates

Func is an extremely versatile super-delegate. So is Action. In my limited experience using c#, every delegate Type I used has an FA form i.e. a derivative delegate type from Func or Action. Examples –

ThreadStart has an FA form “Action”
ParameterizedThreadStart has an FA form “Action”
KeyEventHandler has an FA form “Action<object, KeyEventArgs>”
Predicate has FA form Func

However, Func/Action are not always popular in the BB case as defined in the post about 2 fundamental categories.

Q: so what’s the difference between the FA form and the original type?

Any method to be “chained” into a KeyEventHandler delegate Instance can also be chained into a dlg Instance of the FA form, but the 2 Types aren’t 2 aliases of the same Type. To understand this, let’s go back to basics. In java or c#, Golfer and Violinist interfaces can both comprise a single void play() method, so the 2 interfaces are equivalent but the VM regards them as 2 distinct types and won’t allow casting.

It’s impractical to work exclusively with the super delegates. These types have meaningless names.

Q: So where can the super delegate Types be useful?
A: when you need a throwaway delegate type, like the AA case as defined in the post about 2 fundamental categories.

http://www.codeproject.com/Articles/192027/Delegates-101-Part-III-Generic-Delegates has similar comments on the super delegates

elegate recipe:utility static class2call instance method@any object

Say you have a (shared) _static_utility_ class freely usable from any client class, but this utility class should not “know” about (see http://bigblog.tanbin.com/2012/10/a-service-having-know-how-another-eg-of.html) these client classes.  Suppose the utility class’s main job is to asynchronously call some public WCF query service and provide a static callback method handles data received.

Now suppose some Student1 object (observer) is interested in the query result and would like to receive a callback. Here’s a naïve solution – Student class ignores the utility class and directly invokes the WCF query and privately handles data received. Code duplication in 1) the utility class and 2) Student class.

The better solution is for the static utility class’s callback method (observable) to invoke a (non-static) method on Student1. But then the utility class should NOT hold a reference to Student1, right? Utility class source code should be free of the Student class or any client class. If the util class is in namepace Util, then the util class should not import the Student class into its Util namespace. This way, the util class is reusable in another project without the Student class. If util class were to include “using The.Name.Space.Of.Student” then this class won’t compile without the Student class. Such a util class would be tightly coupled with the Student class.

Solution – utility static class to expose a static event whose type is a dummy void-void delegate. You can also “upgrade” to the standard System.Action delegate, but to illustrate the simplicity of the technique i will use the void-void delegate, probably the simplest delegate in the world.

        public delegate void Dlg1();
        public static event Dlg1 SnapshotsReceived;
        private static void TheCallback()
            SnapshotsReceived(); // fire event

Now our Student1 object can register interest in SnapshotReceived, by passing a Student1 reference (reference to itself) into the static util class ! Under the hood, static class has a hidden static invocation list, each holding a 2-pointer thingy. The Student1 reference is in the invocation list.

unicast delegate=(carefully)generalized func ptr

The delegate construct is related to func pointer, functor, java SAM interfaces … A beginner need not grasp all the relations but sooner or later we have to.

I feel delegate was invented much later and is a generalization of those predecessors.

http://bigblog.tanbin.com/2010/11/delegate-instance-2-field-heap-object.html is the best sound byte I have come up with. ** The 2-pointer construct is innovative. **

delegate element = 2-field heap object, internally

* A delegate instance is a 2-field HEAP object enclosing a Pair of pointers to 1) Target object 2) a method therein.
* A delegate instance is a 2-field HEAP object enclosing a Pair of pointers to 1) a method 2) its host object.

The method signature must match the delegate Type, which is not as restrictive as it sounds — The signature specified in you delegate Type is entirely up to you.

Caveat — this is a so-called simple delegate with an invocation list of 1. Focus on the core issues.
Caveat — the method in this delegate is non-static. Method can sometimes be static but we won’t cover it today.

Remember — a delegate instance is ALWAYS allocated on heap.

[1] is a very short description. Here’s the slightly longer version — At both runtime and compile time, we should view a simple delegate instance as a 2-field heap object enclosing
1) a pointer to a Target object
2) a pointer to a method therein.

In one part of the program, you pass in a target object (possibly “this”) + its method, to instantiate this delegate as a “wrapper” object. You then pass this wrapper around. Often this wrapper becomes a field of an observable object. The observable can then “invoke” this delegate which internally calls the target’s method.

what is a c# delegate, again

This post is mostly about the BB case as defined in the post on 2 fundamental categories.

Let’s try this question again — not simple.

#1 A simple delegate instance holds a method’s address[1] + a Target object [2] to call it on.
** I feel the delegate concept gives more meaning to the traditional “callback” concept
** Argument to the method is passed at invocation time, not creation time. In this respect, delegate == functor.

#2 In practice, a delegate instance often holds a bunch [3] of single-method delegate (instances). Supports append/removeLast. If you program your delegate to be invoked at runtime, all those methods run sequentially by insertion order — key language feature.

Warning — in c# discussions, a “delegate” can mean a delegate Type or a delegate Instance. Always know what is meant in each case.

The Target can be null when we instantiate a delegate with a static method. In that case the full address {class, method} is remembered.

[1] an address, not a a pointer variable
[2]This target thingy is a permanent pointer
[3] actually a reverse singly linked list, known as the invocation list.

c#delegate:closest ancestors]other lang+py

Update — I now feel it’s more practical to separate the 2 (or more) “streams” of thoughts of labmda vs multicast events. The write-up below was written without that seperation. Unnecessarily complicated.

a unicast delegate type =~= a java interface type with a single method, without method body. [1] I no longer subscribe to this.
a unicast delegate type =~= a typedef for a function pointer. This typedef can apply to many functions.

a “delegate” is an instance of a particular delegate type. If we have to build on the java interface idea, then ….

a delegate instance =~= an instance of a stateless concrete single-method class implementing that interface in [1]

a delegate instance =~= a particular stateless functor. Specifically an instance of a functor-wrapper. Note An instances of a functor type is sometimes stateful (see Scott Meyers), but an instance of a delegate type is always stateless.
Update — As explained in http://msdn.microsoft.com/en-us/library/system.delegate.aspx ….
a delegate instance =~= instance of a functor-wrapper having a permanent pointer to the target object myDog, so it could later invoke myDog.jump()

a delegate instance =~= python method object bound to a host object? But stateless??

a delegate type is a distinct type (with a name), a subtype of Class Delegate. Delegate type names typically start with D like “DSomething”

The clue to see the link between a delegate type and a delegate instance is the instantiation expression new DSomething(meth1)

Java’s interface is not really an extension of the c++ functor. C# delegates build on top of java interfaces AND c++ functors.

c# delegate – a few points

See also http://bigblog.tanbin.com/2011/11/c-delegate-closest-ancestors.html

Usage inside c# foundation
– thread creation
– event fields in classes
– GUI event handler
– onMsg() type of thing
– anon methods, lambda expressions

Physical implementation of a delegate instance? unchanged for 20 years —  a wrapper object over a function pointer. There’s only one address for the referenced function, but possibly many wrapper instances.

field-like event syntax restrictions

— based on http://www.ikriv.com/en/prog/info/dotnet/Delegates.html
All events (Field-like or not) always support 2 operations += and -=. You can call them sub/unsub or add/remove.

An event is always a non-static Member of a class. IF compiler accepts your event as a field-like event, then it will accept 2 other operations on it
a) MyEvent != null or == null
b) MyEvent(….);

Internally, these were translated to refer to the hidden private Dlg field generated for every event.

Now, a couple of implications
! subclass can’t use (a) or (b) since the hidden field is private
! You may see (a/b) quite often, but if your event is not field-like, they won’t compile.

delegate invocation list, briefly

— based on http://www.ikriv.com/en/prog/info/dotnet/Delegates.html
An invocation list is a reverse singly linked list, with the last appended “single” as head. Like in hash table buckets, this is optimized for insertion. 

Invocation time — Since this is a singly linked list, we need recursion. Head node’s method (last appended) starts first, invoking 2nd-last-appended.

When you append [d1,d2, d3, d4] to an existing invocation list, system effectively adds d1, then adds d2… (Internally, it could do it faster with pointers.), so I call these d1, d2 .. items “single-method delegates”, or “singles”.

Note the link pointer between link nodes is named “PreviousNode”.

Remove() is by logical-equality, not by reference equality.

##implicit compiler acts on delegates

— Based on http://www.yoda.arachsys.com/csharp/events.html

# MyDelegate d1 = new MyDelegate(this.InstanceMethod1); // when you add this code in a non-static context, the “this.” is implicited added by compiler, but you can add it explicitly

# MyDelegate d2 = new MyDelegate(Class4.StaticMethod2); // the class name, if omitted, is inferred by compiler

# when you call d1(someArg), compiler implicitly calls d1.Invoke(someArg). You do not have to call this method explicitly. Invoke() is useful in reflection. See MSDN

# when you perform d3 = d1 + d2, compiler implicit calls the static Delegate.Combine(d1, d2)
# when you perofrm d3 – d2, compiler implicitly calls Delegate.Remove(d3, d2)

c#event^delegate, again

There are many excellent online introductions of the relationship between events and delegates. Here’s some personal observations —

1) first there’s a difference between an event-field vs an event occurrence (similar to tibrv event). When we say “This class has an event” or “subscribe to this eventA” we mean the field. However, when we say “fire this eventA” we use this big gun named eventA to fire a missile.

2) Virtually everyone commit the crime of ambiguity when they say a “delegate” rather than “a delegate Type” or “a delegate Instance”.

3) we must point out there are

  • delegate types
  • delegate instances
  • delegate variables — local variables, method parameters
  • a delegate field
    • ** a special case — If the delegate field has an “event” modifier, then the field becomes an event field.

It’s confusing and unproductive to compare event fields to delegate instances, or delegate types. Many casual discussions of event vs delegate often bring the delegate instances into the picture, adding to the confusion. Always remember this point whenever there is similarity/confusion between delegateInstance vs events.

An event field is better compared to a delegate variable, but an event field is BEST compared to a non-event delegate field. A non-event delegate field behaves differently from event fields. I think it’s supported and more flexible but rarely used. See

append/removeLast on c#delegate inv list

Note — inv list is like an ordered list. Order is the invocation order. Invocation is strictly sequential.

— Based on http://www.yoda.arachsys.com/csharp/events.html
Like java String, Delegate objects are Immutable — always. Seehttp://msdn.microsoft.com/en-us/library/system.delegate.aspx. Personally, I interpret this rule in terms of the invocation list. (a delegate object’s state is nothing but the inv list.)

Like java String, Delegate concatenation (implicitly using Delegate.Combine()) produces new objects, leaving original objects intact.

  d1 = d1+d2; // appends d2 to the end of d1, both are potentially lists of single delegates.
  d1 += d2; //same thing

Like java String, such assignments __Reseat__ d1 to point at the new object, keeping original objects immutable
Like java String, the “+” operator Appends to the end
Like java String, you can add [d1,d2] + [d2] to get [d1,d2,d2] with duplicates!
Unlike java String, you can Remove too. This illustration is worth 1000 words —

Expression Result
null + d1 d1
d1 + null d1
d1 + d2 [d1, d2]
d1 + [d2, d3] [d1, d2, d3]
[d1, d2] + [d2, d3] [d1, d2, d2, d3]
[d1, d2] – d1 d2
[d1, d2] – d2 d1
[d1, d2, d1] – d1 [d1, d2]
[d1, d2, d3] – [d1, d2] d3
[d1, d2, d3] – [d2, d1] [d1, d2, d3]
[d1, d2, d3, d1, d2] – [d1, d2] [d1, d2, d3]
[d1, d2] – [d1, d2] null

Here’s a bit of the official MSDN spec (adapted) —
The invocation list of a delegate instance is an ordered linked list of what I call “singles”. An invocation list can contain duplicate methods. During an invocation, methods are invoked in the order in which they appear in the invocation list. A delegate attempts to invoke every method in its invocation list; duplicates are invoked once for each time they appear in the invocation list. Delegates are immutable; once created, the invocation list of a delegate does not change.

c# event+delegate #phrasebook

Related to closure?

Event is a non-trivial concept to a guy coming from C. Initially, Focus on the unicast format….

Inside a class Thermometer, suppose you define

public event DHandler Reading;

  • field — an event is a pseudo-field in this class. “Reading” is an event field….
  • type — of this field is the delegate type specified — DHandler
  • field modifier — the 5-letter keyword “event” feels like a field modifier like “mutable” or “volatile”

So what’s the real deal? (Focus – single-listener events) Every Thermometer Instance has a pointer field pointing to a callback functor (or a bunch). This is imprecise but short and sharp. Recall that a delegate-INSTANCE is an instance of a functor-wrapper. Having this field in the Thermometer instance means every Thermometer instance can react to some runtime events, by calling the listener(s) via the registered callback(s). Remember when a listener registers, that object reference is remembered inside the delegate instance.

call — you invoke the listeners like

if (some event happened){
Reading(…args…); //same syntax as invoking a delegate

Internally, this calls _hiddenDlgField.Invoke(…)

observable — In comp science, an “event” typically means the subject/msg-carrier in an observable pattern. In c#, event pseudo-field refers to a list of callbacks.

Listeners — are delegate INSTANCES — basically stateless functors holding both a func ptr and the holst object reference.

http://www.codeproject.com/KB/cs/simplesteventexample.aspx — a simple example

hidden this._target field in a delegate Instance

As stated else where on this blog, an “item” in a delegate inv list holds nothing but 2 pointer fields.
http://www.ikriv.com/en/prog/info/dotnet/Delegates.html sheds light on one of them —

Internally an “item” stores its target in a private field named _target.

Normally, public property Target just returns a value of _target. For static delegates though, _target contains a reference to the delegate instance itself. “Get” accessor of Target makes a quick check, and if _target references a delegate Instance (likely to be itself), returns null.

event pseudo-field ^ hidden delegate field

— Based on http://www.yoda.arachsys.com/csharp/events.html
First let’s review c# properties. Example – Property “age” in class Animal is really a pair of get()/set() methods manipulating a hidden realAge field. You can do anything in the get() and set(), even ignoring the realAge, or make do without the realAge variable entirely. To your clients, age appears to be a field — a pseudofield.

An event is a pseudofield referring to a hidden delegate field. MyEvent is really a pair of add()/remove() methods to append/remove each delegate (one at a time) from the realDelegate field.

If you declare MyEvent without explicit add/remove, compiler generates them around a hidden delegate field, just like an auto-implemented property.

Compared to properties, there’s some additional syntax complexity. The type of the hidden delegate field is the type mentioned after keyword “event”.

closure vs lambda – phrase book

Closure and, to a lesser extent, lambda are difficult to describe, but __implementation__ is easy to understand. http://martinfowler.com/bliki/Closure.html and the wikipedia article are good. Here is my own learning notes and phrase book.

anonymous — an lambda expression is an anonymous function. Simple anonymous functions are handy in many contexts — you know it after you learn to use the technique.

* free — a lambda function always has input variables. It’s like a math function. These variables are by-default “free”. See python lambdas.
* bound — a closure is a lambda with its variables bound to something in the lexical environment

C# delegate? The anonymous delegate might be a lambda.

java — anon inner class offers many features of closure. I feel it’s a reasonable (not the standard) illustration of closure. http://martinfowler.com/bliki/Closure.html explains why it’s Unpopular.

C++ functor — Can’t access a variable in the enclosing “lexical-scope”, so not a closure

value — To the end-programmer, a closure (lambda too) appears to be a VALUE you can pass around, and assign to variables. Stateful object.

stateful — I feel closure is usually stateful; lambda is usually stateless

Garbage-collection — a closure holds almost-permanent references to “variables” (not just objects) in the lexical env, so those variables must not be auto/stack variables. You usually need a GC-powered language.

Many languages’ syntax use the keyword “lambda” to cover both lambda and closures. Reason? I feel lambda vs closure syntax (and implementation) is closely related, and end-programmer will welcome a simplified and unified syntax.

Note closure and lambda are not data types. An end-programmer is forgiven to say closure and lambda are simple flow-control constructs just like a for-loop or if-else. You can point to a chunk of source code and say it’s a closure — or you can say it’s an example-of-closure-Pattern. If I must use a single word each, I would say
* a lambda is a kind of …. function
* a closure is a kind of ….. stateful function

—– confusing/non-trivial jargon to avoid if they don’t help your learning — you can safely skip them
bound variable