| Delphi Clinic | C++Builder Gate | Training & Consultancy | Delphi Notes Weblog | Dr.Bob's Webshop |
 |
 |
 |
| Delphi Clinic | C++Builder Gate | Training & Consultancy | Delphi Notes Weblog | Dr.Bob's Webshop |
|
|
|
| ||||||
Delphi Highlander Preview
From September 25th until September 29th S&S and Borland organised the Borland Developer Group Conference Europe combined with the 10th Der Entwickler Konferenz, in Frankfurt am Main, Germany.
Having spoken at the very first EKon and European Borland conference, and almost every one since that first one, it was good to be back in the NH Hotel and friendly (albeit very smokey) atmosphere.
David I had the honour of starting the conference at the opening keynote, and he too has missed only a single one in the past.Apart from David, there were a number of Borland employees present, including Jason Vokes, Nick Hodges, Jon Harrison, Gerard v/d Pol and a delegation from the local German Borland office, of course.During the opening keynote, David I announced InterBase 2007 (see also press release from the Borland website) gave the latest update on the spin-off (no real news at this time), and mentioned the new Turbo editions of Delphi, Delphi for .NET, C++ and C#.
Delphi Product Address
The Opening Keynote was followed by the Delphi Product address, hosted by Nick Hodges, who started with a slide show that contained - among others - the Delphi Product Roadmap.
Compared to previous versions of that roadmap, there was one item in the slide (not shown on the website at this time) that immediately got my attention.Although Delphi Highlander was depicted as shipping in the first quarter or first half of 2007, there was also an arrow somewhere in the second half of 2007 that said "VCL for CF".When I asked Nick directly if this meant that "VCL for CF" would not be in the initial release of Delphi Highlander, Nick had to admit that this was indeed the case.A bummer for at least some people in the audience who have been waiting a while now for proper CF support, and VCL for CF (still) sounds very nice, but please hurry up thank you very much.
After the obligatory slideshow, Nick ended with some time on his hands, so he also took the chance to demonstrate two new language features that will be included in Delphi Highlander: partial classes and parameterized types.
Partial Classes
Partial classes are a new feature available in the .NET Framework version 2.0, and hence have to be supported by Highlander.Although primarily a .NET feature, Nick hinted that partial classes might also find their way in the Win32 personality of Delphi Highlander.
The idea is very simple: you start with a class definition in one unit, but instead of using the normal class keyword, you now use the class fragment keyword.In the Highlander version that Nick used, the fragment part was not highlighted, but we can expect it to be so in the final version of course.
The example of the first fragment of the partial class that Nick showed was as follows:
unit Unit1;
interface
type
TMyPartialClass = class fragment
procedure Hello1;
end;
implementation
uses
System.Windows.Forms;
procedure TMyPartialClass.Hello1;
begin
MessageBox.Show('Code from Unit1');
end;
end.
This was the first fragment.In order to add other fragments, you can create a new unit that uses the Unit1 (the one with the first fragment), and then declare the TMyPartialClass again as class fragment, this time adding different method(s).The second unit with the additional fragment of the partial class can be as follows:
unit Unit2;
interface
uses
Unit1; // the original class TMyPartialClass
type
TMyPartialClass = class fragment
procedure Hello2;
end;
implementation
uses
System.Windows.Forms;
procedure TMyPartialClass.Hello2;
begin
MessageBox.Show('Code from Unit2');
end;
end.
Note that Unit2 knows about Unit1, but not the other way around.This means that if your application uses Unit2, you would get the complete TMyPartialClass consisting of the code from Unit2 as well as the code from Unit1.But if you would only use Unit1, and not Unit2, then the code from Unit2 would be unknown by your application, so it would only know of the code in Unit1 (still with me?).
program Part;
uses
Unit1,
Unit2;
var
C: TMyPartialClass;
begin
C := TMyPartialClass.Create;
C.Hello1;
C.Hello2;
end.
Someone from the audience asked what would happen if Nick had only added Unit1 to the uses clause.The answer was demonstrated: the compiler would give an error at the line where C.Hello2 was called (since Hello2 is defined and implemented in Unit2).
When Nick was asked why people would use partial classes in the first place, he mentioned the "Designer Managed Code" section in .NET 1.1 (for WinForms and ASP.NET Web Forms), which Microsoft managed to get rid of using partial classes that contained those code sections in separate files.A good idea, but not nearly as good as the clean .DFM (or .NFM or .XFM) files Delphi developers have been using since day 1.Especially if you look at the upcoming need for XAML support, the step from a .DFM file to a .XAML file still seems smaller than going from a source code based solution (even with partial classes), but that's just my opinion.
Ray Konopka then added that the use of partial classes can also be beneficial to a team of developers all working at a very big class, where the use of partial classes could help divide the complete code into smaller sections that are easier manager and shared (without putting the burden entirely on your version control system) with each developer working on his own section in a partial class.
Parameterized Types
Regarding Parameterized Types, I must confess that Nick showed the example only briefly, and mentioned that the syntax could still change between now and the final version of Highlander.In fact, now that I think about it, he didn t even run the code!
From what I could scribble down, the definition of a parameterized type would be as follows:
type
TMyGeneric <aType> = class
function whatever: aType;
end;
The routines would be implemented as follows, using the <> syntax as well:
function whatever<aType>: aType;
begin
...
end.
And finally, a variable declaration would create an "instance" of the parameterized type as follows:
var
X = TMyGeneric<integer>;
Apart from the fact that this example may not be 100% accurate (based on the quick notes I made), Nick made it clear that the syntax could change between now and the final release version anyway.But at least it's know that they are working on it!
Technical Keynote
Later that evening, the Technical Keynote followed, with no less than five speakers from Borland (the five mentioned above).Jon Harrison covered JBuilder, Gerard v/d Pol showed ECO, David I covered Compact Framework development (to help ease the mind of the people in the audience that were a bit upset by the roadmap that showed VCL for CF in the second half of 2007 instead of in the initial release of Delphi Highlander), and Nick Hodges finally gave a very cool nDataStore (or is it NDataStore?) demonstration.I should start by saying that Nick's demo was a real "what's cooking in the lab" thing, and nothing could be interpreted as announcement, promise or anything else.He just showed some cool stuff, and we had a good time looking at it.
So what is nDataStore? It's a fully-managed DBMS capable of allowing us to write stored procedure and triggers using Delphi code, and it's small: only 1.8 MB (after obfuscation only 1 MB, or so Nick said).It can be found in the Borland.DS.Server.dll assembly.
During the demo, Nick showed Delphi source code that could regenerate a database schema, execute create table and other SQL methods, and also contained Delphi source code with the implementation of stored procedures and triggers (he only had to remember to regenerate the triggers after he regenerated the schema).To me, it was not quite clear if the source code he showed was generated, or hand crafted, but it was impressive to see that we can write stored procedure code in plain good-old Delphi (for .NET).
Being small obviously means that CF.NET is also a target for the nDataStore.But, as can be expected from a "what's cooking" session, there were no announcements regarding the availability or bundling of nDataStore.We just have to wait and see, but the demo looked very promising to me.
Apart from the nDataStore demo, Nick also explained that the database team (with returned member Steve Shaughnessy) has been looking at the drivers that are required for both dbExpress and BDP.For the 8 major DBMSs they support, this means 16 drivers.To bring this down, the database architecture in Delphi Highlander will be changed in a way that only dbExpress drivers are needed (sharing a single driver for both Win32 and .NET).Since ADO.NET 2.0 is in effect BDP, as Microsoft implemented all nice enhancements that BDP currently offers over ADO.NET 1.1, this may mean that current .NET 1.1 applications using BDP may end up using "plain" ADO.NET 2.0 or can move to dbExpress when you want to migrate these projects to .NET 2.0.But all this is still based on my personal interpretation of preliminary information, which might chance between now and the final release date.In other words: don t hold me to it.But one thing's for sure: dbExpress is still the major cross-platform data access technology from Borland, which is being extended to include .NET 2.0 as well.
Disclaimer: the information in this article was based on my personal interpretation of the opening keynote, product address and technical "what's cooking in the labs" keynote at EKon 10 / BorCon Europe 206, which provided information that in itself is still subject to change, so please be aware that things might change between now and the official release of Delphi Highlander.