You are browsing the archive for Mono.

Teaser – MonoDroid with Oxygene

August 20, 2010 in .NET, Android, Elements, Mono, Oxygene, Platforms, Visual Studio

Now that the MonoDroid preview is out, I thought I’d experiment a little with Oxygene (aka Delphi Prism), so I ported the “Button” sample to Oxygene. Here’s a taste of what I came up with:

method Activity1.OnCreate(bundle : Bundle);
begin
    inherited OnCreate(bundle);
 
    // Create your application here
    var button := new Button(self);
 
    button.Text := 'Oxygene Says: Click Me!';
    button.Click += method begin
      button.Text := string.Format('{0} clicks!', count);
      inc(count);
    end;
 
    SetContentView(button);
end;

As you can see, there’s not a lot of difference from the C# version.

Obviously, this won’t be in the build that we RTM’ed last week, and will soon be available from our friends at Embarcadero, but it will work with said release. So if you’re a Delphi Prism customer, or just have a fondness for Pascal syntax, keep an eye out here – more info will be available soon, including templates & other support files.

method Activity1.OnCreate(bundle : Bundle);
begin
inherited OnCreate(bundle);

// Create your application here
var button := new Button(self);

button.Text := ‘Oxygene Says: Click Me!';
button.Click += method begin
button.Text := string.Format (‘{0} clicks!’, count);
inc(count);
end;

SetContentView (button);
end;

DA/.NET Client-Side Scripting

April 19, 2010 in .NET, Data Abstract, Linux, Mono, Relativity

We just finished our dataset scripting support for Data Abstract for .NET. DA now lets you define scripts on the server side (inside the schema), that the client will download and hook up to the events of the dataset. Scripting is supported for both the server and the client, and uses the RemObjects Script engine, which provides the ECMAScript (a.k.a. JavaScript) syntax.

An example, take this script for a “Customers” table:

function beforePost(row) {
  if (row["Discount"] > 50) 
    fail('Discount has to be less than 50');
  if (row["Discount"] < 0) 
    fail('Discount cannot be negative');
}
function onNewRow(row) {
  row["Discount"] = 20;
}

Now any time you fill a DataTable, on a remote data adapter with the script engine property set will receive this JavaScript from the server, and assign them to the datatable:

    var lDs := new System.Data.DataTable();
    lDs.TableName := "Customers";
    RemoteDataAdapter1.Fill(lDs, WhereExpression(nil), true);
 
    var rows := lDs.Select;
 
    rows[0].BeginEdit;
    rows[0]['Discount'] := 60;
    rows[0].EndEdit; // will fail here with a ScriptingException "Discount has to be less than 50"
 
    var lNewRec := lDs.NewRow;
    // lNewRec is preinitialized with a discount of 20 here.

Unit tests for this new feature have been written and all is working nicely. Next will be the same feature for the Linq Remote (and Local) Data Adapter.

Of course, client side scripts are there only to provide immediate user feedback, not to enforce business rules. For this reason, DA will run this business rules script not only on the client, but (where applicable) also on the server. DA also provides a range of additional server-only script events that can implement more extensive business logic – something i will talk more about, soon.

Delphi Prism in MonoDevelop at a glance

March 29, 2010 in .NET, Elements, Linux, Mac, Mono, MonoDevelop, Oxygene, Platforms, RemObjects, Tools, Windows

Our beta users (marc already did mention you can apply for the Prism beta here, didn’t he?) are already playing around with this for some time now, and we are going to ship it with the upcoming release: the Delphi Prism MonoDevelop integration. Marc already mentioned this some time ago and a lot has happened since then. This article should give you a ‘what is it and how could I start?’ introduction into Delphi Prism in MonoDevelop.

MonoDevelop LogoMonoDevelop is a free and open source .NET IDE. and has its roots in the also free and open-source SharpDevelop .NET IDE. With SharpDevelop still being a Windows-only IDE using Windows Forms, MonoDevelop (or in short MD, as we call it internally) was ported to Gtk# and massively extended in regards to cross-platform compatibility. It is now able to work smoothly on Linux, Mac OS X and, of course, Windows. You can use your solutions from Visual Studio with MD and vice versa, so you are able to have a single source solution for different platforms.

With the Delphi Prism MonoDevelop integration we target mainly the Mac and then Windows. For Windows we have the Visual Studio integration and we ship the Visual Studio Shell which is, in fact and to be honest, a far more comfortable and powerful IDE. That said: Of course we want to make sure that MonoDevelop on Windows (MD/Win) also works like a charm, but MD/Mac is of a higher priority because you don’t have an alternative IDE there.

The MD/Mac flavor of our MonoDevelop integration comes in form of a complete Mac application. It looks like it’s the original MonoDevelop, but additionally contains our Delphi Prism plug-in. That means you will have to install the MonoDevelop prerequisite by yourself (which is Mono >= 2.4). You can grab it here.

After startup, the Delphi Prism will tell you that it is not licensed and ask you to register your license (if you don’t have a Delphi Prism license yet you can get your copy and a 30-day trial key from the Delphi Prism download page).

When selecting “Start a new Solution” you have several options: The first one is a Console application, but you also have the choice to work with ASP.NET projects, create iPhone or iPod touch applications (be sure to have the iPhone SDK and at least the Trial of MonoTouch (http://monotouch.net/) installed for this) and you can build Moonlight applications (the Mono alternative to Silverlight).

For this article we’re going for an iPhone application. Not because we want you to go and buy you into the iPhone Developer Program and additionally buy MonoTouch from Novell, but just because it’s a neat thing to show ;)

In this dialog you see the options I set for the Hello world iPhone application. Be sure to meet the requirements (MD prereqs, iPhone SDK and MonoTouch) if you want to follow this article in code yourself. The next thing you’ll see is the MD editor with the project opened and ready to start.

We’re not going too deep into the MVC approach of the iPhone development, which is also the key to general Cocoa development, but you need to know that the UI is separated from your code. Unlike in Delphi or Windows forms where controls dropped on the form are automatically properties of your form class, you need to define which controls and events (called Actions) are visible to your code using defined classes.

The first thing we’re creating is the GUI. No demo without a ‘Hello World’, so we simply want to display the text entered in a text box on a label when the user presses a button. In the ‘Solution’ part of the MonoDevelop IDE to your left we expand the project and double-click on the ‘MainWindow.xib’ file. This should launch a program called ‘Interface Builder’ which belongs to the iPhone SDK. The .xib file is somewhat compareable to .dfm files you know from Delphi or like .Designer.pas files which define the layout of a Windows Forms form. The following part of designing the GUI and connecting the outlets and signals is in fact the most difficult if you never worked with interface builder. Because of that I also created a short video of this walk-through so that you have the chance to actually see what I’m going to describe now.

S1.png

On the ‘Library’ window you select the ‘Objects’ part on top and use the search box on the bottom to search for a ‘Toolbar’. Take it and drop it on the window and let it dock on the top. Then do the same for a ‘Text Field’ and a ‘Label’. You can drag them to the width that pleases you. Now that all controls are in place it’s time to make them accessible. In the ‘Library’ Windows please select ‘Classes’ on top and type ‘App’ in the search box. Then you can select the ‘AppDelegate’ class which is the interface between our application code and the GUI. Still in the library window select ‘Outlets’ in the lower half. We’re going to define accessors to the text field and the label now by clicking on the ‘+’ below the listed outlets and enter text and repeat that for label. Now we’re going to make our click event accessible by selecting ‘Actions’ instead of outlets and add the action ‘onClick:’ (mind the colon!) to the AppDelegate class.

The next task is to connect our outlets and the action to the controls. To do this, you simply select the toolbar button (labeled ‘Item’) in the window. In the property window you select the connections (white arrow on blue circle). There is an area called ‘Sent actions’ with an entry for ‘Selector’. Use the mouse and click in the circle to the right and drag this on the yellow ‘App Delegate’ box in the ‘MainWindow.xib’ window. On dropping you are able to select the action you want to link with the sent ‘selector’ action of the item. For both the text field and the label drag the ‘New referencing outlet’ circle on the App delegate and link them to the text and label outlets we defined before. Now you can press Apple+S to save the MainWindow.xib file.

MonoDevelop generates the code behind for us automatically. Please open the ‘MainWindow.xib.designer.pas’ file (expand the ‘MainWindow.xib’ node in your solution to find it) to have a loot at the generated code. Locate the

method onClick(sender: MonoTouch.UIKit.UIBarButtonItem); partial; empty;

line and copy it (withouth the empty;). Pase that in the ‘private’ section of the ‘AppDelegate’ class in the Program.pas file and double check that the empty; part did not get pasted too. This is the method that get’s called when the event (sorry, Signal ;-) ) fires from the GUI. In the implementation part complete the partial method and fill in it’s body:

method AppDelegate.onClick(sender: UIBarButtonItem);
begin
  label.Text := textbox.Text;
end;

In fact that’s all. Compile the project using the building blocks icon in the toolbar of MD (or by pressing Apple-B). Your code will be compiled into an assembly and the assemblies then will automatically be compiled in to native code for the iPhone by the MonoTouch compiler. When clicking on ‘Run’ or ‘Debug’ the iPhone simulator application should pop up and run our Hello world application:

S2.png

As you can see building an application for the iPhone using Delphi Prism is not only working, but you can make use of the full Cocoa API the iPhone SDK is offering you. Of course this only works if you have the iPhone SDK and MonoTouch, but to develop for the simulator as we just did, the free version of both is enough. You would only need to pay for the Apple developer program membership and for the MonoTouch licence if you’re going to deploy your programs on a physical device. In other words: Unless you want to start selling your application and earn money in return, you can work for free.

Here you can watch a little video that shows how the application was build:



Download this Video: as mp4 or in open ogg format.

This was a first feature preview of Delphi Prism in MonoDevelop and we hope you like it and stay tuned for more.

Sebastian

Avatar of marc

by marc

Episode 39 of the Podcast at Delphi.org

March 19, 2010 in .NET, Cocoa, Elements, Mac, Mono, MonoDevelop, Oxygene, Podcast, Visual Studio

It’s been a long while, but Jim and i finally found the time again to sit down and record a new episode of The Podcast at Delphi.org, talking about the upcoming Delphi Prism 2011 release, software development for the mac using Mono, and a lot more. It’s been great to be back on air, and we’ll hope to make this a more regular thing once again. In the mean time, i hope you’ll enjoy this episode!

See the official post for this episode at Delphi.org. Or subscribe in iTunes or via the RemObjects on Air feed.

(Via The Podcast at Delphi.org.)

Avatar of marc

by marc

What’s New and Cooking…

March 6, 2010 in .NET, Data Abstract, Delphi, Mono, Oxygene, Relativity, RemObjects, Visual Studio, Xcode

The past week has been a busy one, here at RemObjects. On Tuesday, we shipped our new “Spring 2010” releases, updating our entire product suite. We also started work on three major new projects that will significantly shape Data Abstract over the coming year.

Let’s start with a quick look at the “Spring 2010” releases. On first sight, this round looks like a minor update – and in many ways it is, as a large portion of the past product cycle has been concentrating on QA and documentation (which is making great strides in the wiki, i must say – kudos to the entire team for keeping up with their documentation writing). But we also shipped a few great new features and key technologies that will play an important role moving forward.

Script

Firstly, there’s the new RemObjects Script for .NET that Carlo talked about the previous week. Right now, RemObjects Script is is shipping as a standalone library product (like its close sibling Pascal Script for Delphi, and like Internet Pack, it ships free and with complete source, and is available in our public SVN). So that alone, i believe, is pretty cool – but RemObjects Script fits into a greater plan, and that is the expansion of Business Rules Scripting in Data Abstract.

A little known and often overlooked feature we have had in Data Abstract for Delphi for a long time is the ability to define business rules inside the schema, to be run on the client. Not really meant to enforce security, but more to provide a better client experience, the idea was that constraints and business logic could be specified – using Pascal Script – right inside Schema Modeler, and clients will retrieve and run these rules automatically, and would always have the latest set of rules, without needing to update the client .exe.

RemObjects Script is an essential piece in our plan to take this to the next level, and we are currently working on full Business Rules Scripting support, both client and server side, and for all three editions of Data Abstract. The idea is that right inside Schema Modeler, you will be able to specify JavaScript based rules that can run either on the client (be it .NET, Delphi or OS X), the server, or both.

Server side rules can be used for the actual enforcement of rules, making it possible to replace a lot (if not all) of the code that currently makes up a common DA server. Client (and shared) rules can complement these to enhance the local editing experience, by “enforcing” adherence to rules while editing data, without requiring a roundtrip to the server for final validation.

This DA Scripting feature is in the works now, and will ship for the various editions over the remaining course of the year, starting with Data Abstract for .NET in May.

Relativity

Next up, we shipped the first release of Relativity. Relativity is our new standalone Data Abstract application server, replacing the aging (and Delphi based) DAServer.

The idea behind Relativity is that the vast majority of Data Abstract servers don’t really need much custom code (beyond business rules), yet the common Data Abstract approach today is to create a custom server .exe that needs to be built, deployed and maintained. With Relativity, this can now be a thing of the past, and you can deploy Data Abstract services in a ready-made server application, simply by uploading the appropriate .daSchema file.

Relativity is based on Data Abstract for .NET, but it ships with all three editions of Data Abstract. This means it gives Delphi developers the chance to use .NET drivers and the advanced server-side functionality such as DA SQL, without needing to purchase (or learn to work with) DA/.NET. It also allows Mac and iPhone developers to create and host servers (since we don’t ship a server library in DA/OSX).

And of course Relativity will also take full advantage of DA Scripting, starting in May.

More Stuff

In addition to these to “big ones”, we’ve also shipped a range of smaller new features and enhancements.

Internet Pack for .NET has been extended with a native client implementation for LDAP, which Carlo also blogged about before. We use LDAP a great deal internally, and this new client class makes it easy to build LDAP authentication into your RO/DA servers (or any other applications, of course). In fact, Relativity ships with a default LDAP Login Provider that is based on this implementation.

Data Abstract for .NET now provides the ability to expose data via the REST protocol, which makes it very easy to access data from non-DA client applications, for example from client-side AJAX based web sites. REST is one of many features we have added over the past year or so to enable better accessibility from web clients (another notable one is support for JSON messaging in RemObjects SDK), and we’ll be blogging and writing more abut this.

Our Xcode integration has been extended by new project templates that really make it easy to get going with Data Abstract or RemObjects SDK for the Mac or iPhone. These templates were created based on a lot of custom code i had written while implementing our internal Bugs 7 client, and they should provide a great starting point.

Screenshot 1 - Templates.png

(One of the next items on my list is a post that will look at these in more detail).

 

Visual Studio 2010The last important change i want to highlight is that the entire range of products for .NET is now compatible and integrates with the new Visual Studio 2010 (based on the current Release candidate, although we expect no problems between now and the final release of vs2010 in April).

What’s Next

Ok, so i mentioned work on three new major features has started this week, as well. What are those? The first one, of course, is the new DA Scripting support i mentioned above.

The second new feature is one that we have been planning for a while but are finally getting around to for this time, and that is a brand new “New Project” template architecture for both Delphi and .NET. The current templates are pretty server-focused, and don’t make it very easy to create different client types. Our new templates will be focused around ann the various client applications you might want to create (WinForms, WPF, Gtk#, Silverlight, Monobjc, ASP.NET, VCL, UCL, and so on), combined with a great integrated wizard that will allow you to either create a new server project to match, or connect your client to an existing (custom or Relativity) server.

The third new feature, which i am most excited about, is to round of our Mac development story to allow for pure Mac development of DA applications. We have the library to build great clients on Mac, iPhone and iPad. We now have Relativity to host DA services on a variety of server platforms. What’s missing, and what we’re working hard on for the May release, is the tool chain in the middle – a Schema Modeler for Mac that will enable developers to design and test their schemas, for Relativity deployment, right in their Mac.

 

Stay tuned for a lot more talk about all three of these topics, over the next three months. In the mean time, go and check out our “Spring 2010” releases, available now!

 

marc

RemObjects Script for .NET

February 23, 2010 in .NET, Data Abstract, Mac, Mono, Oxygene, Visual Studio

A while ago, I started planning a new Data Abstract feature: we wanted to support scripting in the .NET parts of the product, for validating business rules on both the client and the server, and for writing server logic, like we already have in Data Abstract for Delphi. There were several options we considered to us to use:

  • IronPython/Ruby
  • JScript.NET
  • Active Scripting JScript COM objects
  • CodeDom (C#, VB.NET)

But each came with it’s own problems. CodeDom, IronPython & IronRuby wouldn’t work for the Delphi and OS X side of things, and we wanted the new solution to be compatible across platforms. JScript.NET was deprecated a while ago and isn’t updated anymore, and the JScript COM objects aren’t very easy to manage from .NET, and wouldn’t work on Mono.

So what we did instead was write our own JavaScript (or as it’s properly called ECMAScript) engine. Microsoft had just introduced the new DLR, so we decided to base it on that, to have a good framework that would let us have an implementation with good performance and interoperability with other DLR and non-DLR based languages.

Initially, the development of this went rather slow, as the DLR at the time was very new, not even a 1.0 version was available, there were few docs and the samples online were hopelessly out of date. Adding to that was the problem that every update of the DLR code changed something. But now the DLR is becoming quite stable and parts of it will be in the soon-to-be released .NET 4.0 framework.

Introducing Script for .NET

Script for .NET is the end result of this work, and it’s a free-with-source implementation of ECMAScript (edition 3). It has all the features expected from JavaScript and the default (non-browser) objects like Object, Array, Function, Math, Number, Date, String, Boolean and RegExp. As mentioned above, the engine is based on the Dynamic Language Runtime, but it works on version 2.0 and later of .NET, as well as on Mono.

Debugging Support

The engine includes support for in-process debugging by the host, allowing to step through, step into and step out of the current function, and inspect all the locals and their current state. The following screenshot of one of the included sample applications shows this i action:

Usage

To make the engine easier to use, the class library includes an EcmaScriptComponent class which wraps the DLR and Scripting engine, lets the application run and debug arbitrary scripts, as can be seen below.

 
private void ShowMsg(string s)
{
  MessageBox.Show(s);
}
 
 
  ScriptEngine = new EcmaScriptComponent();
  ScriptEngine.Globals.SetVariable("ShowMessage", new Action<string>(MessageBox.Show));
  ScriptEngine.Source = @"
    var pi = Math.PI;
    ShowMessage('Todays value of PI is : '+pi);";
  ScriptEngine.Run();

It is also possible to and expose classes or complete .NET assemblies to the engine for use from within the script:

  ScriptEngine.ExposeAssembly(typeof(System.Object).Assembly); 
  // exposes all namespaces in mscorlib.

Where to get it

You can read more about RemObjects Script on its product homepage. The project itself is maintained on our code.remobjects.com open source repository, with full access to the SVN and bug tracker. The Spring 2010 release is available for download, now.

With the script engine itself out of the way, we are now working o the integration with Data Abstract, for our Summer releases.

Avatar of marc

by marc

New Expression Types in Delphi Prism

February 20, 2010 in .NET, Elements, Mono, Oxygene

It seems the sneak peek at “for expressions” in my previous post caused quite a bit of stir, so i figured i would spend a few minutes talking about the new expression types in general.

As you probably know, if you ever stopped to think about Pascal grammar, the most basic component that makes up a method body is a statement. A method body is pretty much defined as a list of statements, separated by semicolons. x := 5 is a statement. MyObject.DoSomething is a statement. Even a begin/end block is a statement (containing, nested within itself, another list of statements).

There’s a special kind of statements that seen frequently, and that are expressions. An expression is a statement that has a value, and as such, can be used in any code construct that expects a value – such as on the right side of an assignment, within arithmetic formulas, or as parameter to another method, for example. 5 is an expression. so is MyObject.ToString.

(In early Pascal, expressions did not use to be full statements. For example, functions (ie, procedures that return a value) could not be called without making use of that return value. In other words, sqrt(9) was not a valid statement, although x := sqrt(9) was. But that’s a thing of the past).

Functional Programming

Where am i going with all of this? Well, with the upcoming Spring 2011 release of Delphi Prism, we have extended the language. We took three commonly used statements, and we turned them into expressions.

This was done as part of an effort to bring more functional programing concepts to the language. Functional programing has been a niche in commercial software development for a long time, with most of the limelight going to (first) procedural and (later) Object Oriented programming, the latter of which is sort of a natural evolution of the first.

Functional programming uses a quite different paradigm, but it turns out that it is a very good fit for writing efficient multi-threaded code, and that’s why functional programming has been seeing a big revival over the past year or so, with developers looking at Erlang or Haskell. Microsoft has also stepped up its work on F#, a functional language for .NET, and is including that as a first-tier language in Visual Studio 2010.

For Prism, we decided to take a slightly different approach, and see if we could – over time – extend it with elements from functional programming languages, but, as has been the goal with Prism from day one, keeping them in line with traditional Pascal syntax and feel. (F#, for example, has many interesting concepts that make for a powerful language – but a god-awful and near-incomprehensible syntax to go along with them).

Our new expression types are a first step in that direction, so let’s have a look at them:

“if” Expressions

“if” statements are the bread and butter of just about every pascal method, allowing the conditional execution of one of two statements, depending on a boolean condition:

  if Condition then
    ThenStatement
  else
   ElseStatement;

The key word here statement. Both the then and the optional else case contain a statement (not an expression!) they execute, and as result, the entire if clause is a statement (but on an expression).

We have extended this syntax to allow the entire “if” clause to become an expression, if the statements it contains are expressions, as well. in other words, you can now write

  if Condition then
    ThenExpression
  else
   ElseExpression;

and the entire construct is an expression, representing the value of either ThenExpression or ElseExpression. To give a real life example, you could write:

  s := 'The Condition is ' + if Condition then 'true' else 'false';

The type of the “if” expression (in this case, a String) is determined by the lowest common denominator of the two expressions. If the optional else clause is missing, the result for a false condition will be nil, and if the type of the then expression is a value type, the “if” expression will be a nullable type. In the following example:

  var x := if Condition then 3;

x will be a nullable Int32, and contain a value of either 3 or nil.

“case” Expressions

The same extension applies symmetrically to “case” statements. A case statement where each individual case is an expression becomes an expression itself. As with the “if” expression, the type will be the determined by lowest common denominator of all the contained expressions, and if no else statement is provided, it will be nullable.

For example:

  s := case Number of
         1: 'One';
         2: 'Two';
         else 'Many';
       end;

I hope looking back, it makes sense why went into such detail with regard to statements vs expressions, at the start of this post. The point, really, is that expressions are just a sub-type of statements that have a value. And if you think about it, there’s really no good reason why the above statements/expressions should not have a value, and thus be expressions.

“for” Expressions

The last new type of expressions i want to talk about are “for” expressions. As with the other two, we have taken the regular “for” loop statement, and enabled it to be an expression:

  for each x in SomeSequence yield Expression;

and

  for x := StartValue to EndValue yield Expression;

As you can see, the syntax for this uses a slight variation on that of regular “for” statements, by replacing the do keyword with yield. This is mainly because yield makes more sense in the context of an expression. do implies execution, but we’re really yielding the value for each iteration of the loop.

If this sounds familiar from another feature in Delphi Prism called iterators, then that is no accident. A “for” expression has very much the same attributes and behavior of an iterator – in fact, you could think of them as “anonymous iterators”.

So what is the value of a “for” expression? The mentioning of iterators and the use of the yield keyword may have given it away: the value of a “for” expression is a sequence containing each of the individual expressions.

For example:

  var SomeNumbers := sequence of Int32;
  SomeNumbers := for i: Int32 := 0 to 100 yield i*i;
  // SomeNumbers contains the squares of 0 thru 100

And, just like an iterator, this sequence will be generated on the fly, as it gets enumerated. In the example above, no code runs to actually “calculate” the numbers 0 thru 10000 – the “for” loop itself is an O(1) operation. It’s not until we access the sequence – for example thru another for each loop, that the actual squares will be calculated.

To give an extreme example it’s entirely fine to declare the following

  var AllInts := for i: Int64 := 0 to Int64.MaxValue yield i;

to get a sequence of all (positive) Int64 values. We could then loop over that, using say

  for each x in AllInts index i do begin
    // only handle first thousand items. else we'd be at it forever.
    if i < 1000 then break;
    Console.WriteLine(x);
  end;

Summary

And that’s the new expression types, one of many new features in the upcoming Spring 20112010 release of Delphi Prism. If you’re part of the field test (and if you’re an active Delphi Prism customer, you really should be!), you can see these in action in the current beta drop.

Let me know what you think, and stay tuned for more!

Avatar of marc

by marc

New Syntax for Extension Methods in Delphi Prism

February 17, 2010 in .NET, Elements, Mono, MonoDevelop, Oxygene, RemObjects, Visual Studio

Ever since Extension Methods have been introduced in .NET 3.5, we’ve been pondering on a proper syntax to allow developers to define their own. C# uses an awkward syntax where it uses the this keyword (C#’s equivalent of self) as name of the first parameter. But that felt wrong. For one, it’s a very C-like thing to do (having an obscure syntax that is not really discoverable or understandable, it ranks right up there with =0 for abstract methods in C++), for another, the fact that methods receive a self pointer as first parameter shoud be an implementation detail of the language (or runtime), not a syntax feature.

Another idea was to simply allow a new extension directive to be appended to a method declaration (similar to virtual or similar constructs). But that too felt wrong.

So what we did, for the time being, was to not provide any special syntax at all, and let people simply define extension methods “manually”, by applying the appropriate attributes. Given that extension methods are consumed (which we have always supported) much more often than defined, we figured this was a good enough compromise, for the time being.

Then, a couple months back, i was doing some language research, among with was watching the introduction video for Go, the new system language created by Google. While in general Go’s syntax felt, to me, like C/C++ beaten with the ugly stick (no offense), it introduced some nice concepts, and one thing that struck me was how easily Go allowed to declare new methods for a class.

This, i thought, was how extension methods should work like, in Prism. An extension method, ultimately, should not have to be part of some arbitrary class that has nothing to do with that method or with the class you are extending. Forcing extension methods into a class syntax is not proper Object Orientation – on the contrary, it’s an abuse of OO syntax. And why shouldn’t you be able to just go ahead and declare the method – without having to learn some awkward syntax or rules?

i decided you should, and after convincing Carlo to do the actual implementation, i am happy to let you know you that starting with the upcoming Spring release of Delphi Prism, you can now define extension methods by, well, just defining them.

Behold:

extension method Int32.Twice: Int32;
begin
  result := self*2;
end;

If we overlook the new extension keyword for now, this looks like a regular method on Int32 – which, essentially, it is. There is no need to define an awkward “self” parameter; you just specify the method name prefixed with the type – as you’ve done thousands of times when writing your own classes – and the compiler takes it from there.

Only the extension keyword indicates that Int32 is not really your own class, but that you’re extending a class defined somewhere else.

This new syntax should make it much more convenient and attractive to define new extension methods, when and where you need them – without all the overhead of a class declaration.

Of course this works on more complex types, as well; the following complete program prints the square of all numbers between 0 and 100 – not by squaring the numbers, but by squaring the sequence of numbers. (It also shows off two other new language features we haven’t talked about yet ;)

namespace ExtensionMethods;
 
interface
 
uses
  System.Collections.Generic,
  System.Linq;
 
extension method IEnumerable<Int32>.Squared: IEnumerable<Int32>;
 
implementation
 
extension method IEnumerable<Int32>.Squared: IEnumerable<Int32>;
begin
  result := for each value in self yield value*value;
end;
 
begin
  var values := for i: Int32 := 0 to 100 yield i;
 
  for each i in values.Squared do
    Console.WriteLine(i);
end.

Let me know what you think!

Using LDAP for User Authentication

February 8, 2010 in .NET, Data Abstract, Mono, Visual Studio

We at RemObjects Software have been using LDAP for centralizing the authentication for all our different projects, like our issue tracker, internal websites, calendar and jabber and it’s been working very well. However for .NET there’s only one library that can be used on both Mono & .NET to talk to an LDAP server, namely Novell.Directory.Ldap.

While this library supports all the features one could want out of an LDAP implementation, it had some issues with records not arriving when talking to an OpenLDAP server, so what we did is write our own, as part of InternetPack. It’s a simple LDAP client implementation but offers everything required for searching records and authenticating and supports both LDAPS and StartTLS over LDAP.

Simplifying the process

Included with the new LDAP classes is a wrapper that, given a few properties, handles the following:

  • Find a user by name, not by it’s full LDAP distinguished name
  • Validate the users’ credentials
  • Return the list of groups this user is member of
  • Return all available info about the user by returning it’s user record

We’re using this new class internally already and it works very well, but any comments on it would be appreciated. For those that are new to Internet Pack: it’s free.

Dev Diary – an Introduction to Shimmer

January 18, 2010 in .NET, Mono, RemObjects, Tools

In the Mac world, there’s a great little library called Sparkle. It uses RSS feeds to facilitate the distribution of software updates, with a minimum of code required in the application. Our illustrious CEO, marc, has been talking about it for a while, and we use it internally in several of our Mac applications.

shimmerHowever, the .Net world doesn’t have anything quite like it. After some discussion about what we needed in such a library, I decided to write shimmer. It will have much of the same functionality as Sparkle does, with some additional things that are necessary for the .Net and Windows environments, as well as being able to run on Mono on most supported platforms. For the time being, it’s an internal project, that will see the light of day first in our new bug tracking client. Will it ever be released further than that? We haven’t decided yet. Let us know if you’re interested, and we’ll consider our options.

I’ll be chronicling my adventures during the design and coding process for shimmer here over the next few weeks.  I hope you’ll find it interesting. :)