Until a very good usage scenario (maybe inspired from C#, JavaScript, Ruby, Groovy…etc) of closures will not be provided (adapted to Delphi) … we will just continue to be biased against the creepy syntax …

I just assume that anon-methods (closures) were added to Delphi (currently just in Win32/ no .NET mention) to align to the current modern language features (.NET family + dynamic ones) and also to support future devel as native Delphi Linq-like syntax sugar [maybe using sets ?] and future C++0x lambdas… Just a guess…

Barry just promised us some real-word examples for Delphi closures … so lets press Barry for releasing these gems

Others may like this; I’m glad I don’t need to use them if I don’t want to.

function VeryComplicateFunction(const x,y:integer):integer;
begin
// hundreds LOC, but for simplicity like in the example:
Result := x + y;
end; // VeryComplicateFunction

//**************************************************************

procedure TFOO.DoTheTest;
var
MyNumber : integer;

//————————————————————–

{sub}function SimpleFunction(const Number:integer):integer
begin
Result:=VeryComplicateFunction(MyNumber,Number);
end; // SimpleFunction in DoTheTest

//————————————————————–

begin
MyNumber:=20;
Writeln(SimpleFunction(22)); // writes 42
end; // DoTheTest

//**************************************************************

Or better yet, define "TFoo = reference to class…" and get the same automatic refcounting, with no need to FreeAndNil explicitly?

Our modus operandi is to declare an interface for every new class we create, just so we don’t have to sweat the memory management. But I’d love to be able to do the same thing with less typing.

I’m not sure what this means, but I get that direct assignment to event handler slots will not be possible. A pity.

Method references are managed types, while events are method pointer-valued properties, and method pointers are unmanaged types. Thus, for type-safety reasons, assigning method references to method pointers is not supported.

The primary motivation behind using method references is to have a type that can contain a closure value. Since closures close over their defining environment, including any local variables reference at the point of definition, they have state that must be freed. Method references, being managed types (they are reference counted), can keep track of this state and free it when necessary.

If a method reference or closure could be freely assigned to a method pointer, such as an event, then ill-typed programs with dangling pointers or memory leaks would be very easy to create.

The easiest and best, but possibly not most convenient, way to assign a method reference or closure value to an event is to ensure that the event a method reference type.

http://en.wikipedia.org/wiki/Closure_(computer_science)

There is a good deal of discussion about it on the net, but it is mostly with languages such as lisp, python, ruby, javascript, C# and so on.

It is a technique for solving some kinds of problems efficiently, just like OOP is a technique for solving some other kinds of problems efficiently.

Andreano, in Tiburon can we assign closures to delphi events if the calling signature matches? I expect this would be one of the more common uses.

Utterly unnecessary as far as I can see, and a potential source of confusion. After all, why not:

var
o: reference to TObject;

Just as redundant but at least consistent (with the new incantation). Or does the use of "reference to" confer some special properties on these types that is not present in "regular" function/procedure pointer types?

It’s the only explanation I can think of.

I also share similar concerns to those expressed w.r.t on-going maintenance of code that uses this stuff.

Really, apart from the binding to local variables, what does this really offer that existing function pointers do not already provide in an arguably much clearer (certainly more easily understood) fashion?

In C# (the aping of which is what ultimately lies behind this stuff) the need was clear, to avoid delegates and so streamline things. Here, the "solution" is less streamlined than what we already had (and still have?)

As I understand things though, this was also needed in C# for the LINQ implementation (initially a huge piece of "WOW" functionality that is rapidly losing it’s appeal - and traction - as pointy sticks get prodded at it). Heck, even within Microsoft the great standard bearer for LINQ (LINQ for SQL) is looking a bit pathetic now that ADO Entities are here.

If I recall, the local variable binding stuff is (partly at least) the LINQ connection in this area. And sure, it has real "cool - wow look at that value" when you look at trivial little demos. Put this sort of stuff into even slightly more than non-trivial production code however, and the price will be paid in spades when some poor sap has to come speluncking through the code in months/years time and try to figure out how to fix some bug or other.

This is a BAD direction for Delphi to be going in, leading, as it does, right up to the door step of C#.

If Delphi is to become just a Pascal imitator of C#, I think most people are just going to say "to hell with it - let’s just use C#. It’s Microsoft, and it’s on the front edge of the language curve, as opposed to this CodeGear C# wannabe, which is way behind the curve and, well, isn’t Microsoft. So what if C# is potentially slower, it’s so gosh-darn sexy. Phwoarr!"

The great advantage that Delphi used to have was that it was just as powerful as C++ but a darn sight more pleasurable and productive to work with (on an on-going basis, rather than a "sexy toys to spew out code, and we’ll worry about the maintenance issues when they arise" basis).

Ugly, inscrutable code is the order of the day in the C# camp, so new functionality that is also ugly and inscrutable at least fits comfortably in (especially when it cuts down on SOME of the existing ugliness and inscrutability).