Delphi Prism Language - What you can do
Delphi Prism brings a lot of new features in the language, here a list of new thinks you can do.
var
path : String := System.IO.Path.GetFullPath(tbDatabase.Text);
db : DataContext := new DataContext(path);
begin
var i : Integer := 0;
var contacts := from contact in db.GetTable<Contact>() select contact;
property ContactID : Integer;
property FirstName : String;
property Email : String;
property ModifiedDate : DateTime;
case l_action of
‘logout’: begin
…
end;
‘login’: begin
…
end;
else begin
…
end;
end;
class method Program.Main(Args: array of String): Integer;
begin
if Length(Args) <> 1 then
begin
Console.WriteLine(‘Argument not found!’);
exit 1;
end;
RunWith(Args[0]);
exit 0;
end;
Result is:
Stay tuned, you can do much more with Delphi Prism.
Share This | Email this page to a friend
Posted by Andreano Lanusse on November 19th, 2008 under Delphi, English |7 Responses to “Delphi Prism Language - What you can do”
Leave a Comment
Server Response from: blogs2.codegear.com



November 19th, 2008 at 3:09 pm
Most features look interesting.
But two of them are kind of ugly.
Initializing a variable like this:
path : String := System.IO.Path.GetFullPath(tbDatabase.Text);
That’s bad because var should not contain any non-constant-code (i.e. code that can only be executed at run-time). That’s the whole point of having a var section!
Second ugly thing is how aysnchronous methods are called. It is bad to just add async; at the end of the declaration instead of putting it in front of the call. I found myself searching quite a long time until I found what part of the code is asynchronous. This is bad and dangerous!
From just reading
lMyConsoleApp.Test()
it is absolutely NOT obvious that this call is asynchronous.
It is MUCH better to add a specifier in front of the call, something like:
asynccall lMyConsoleApp.Test()
or whatever.
November 19th, 2008 at 3:11 pm
Correction:
—————-
Initializing a variable like this is bad:
var
path : String := System.IO.Path.GetFullPath(tbDatabase.Text);
begin
…
end;
I forgot to add the var-keyword in my first post.
November 19th, 2008 at 4:13 pm
Hi Mael,
About async, there is other way to declare, like this.
async for i := 0 to 10 do begin
…
end;
or
async begin
…
end;
About the variable, this is just an example, but for better example you can do something like this.
var
obj : TList := new List();
November 20th, 2008 at 12:50 am
I dont like:
"Variable everywhere and create a instance at the same time you declare."
This will result in ugly unreadable code (=VB). Not nice.
I like:
"Properties - implict read and write, declare only when necessary"
Great.
"String support in case statements"
Waited for that long, great!
November 20th, 2008 at 6:21 am
Hi Andreano,
Very nice.
Any plans to include these new languege features in the Delphi/CB Win32 Compiler?
Thanks
November 20th, 2008 at 7:56 am
Hi Andreano,
Thanks for your response! Your alternative syntax is much better. If you plan to add that Prism feature to Delphi.Win32/64 please consider to only use the alternative you showed last. The first one (async at end of method declaration) can lead to unexpected race conditions (you expected it to execute synchronously since no explicit async statement is there). And I can see that causing many troubles and hard to spot bugs, especially for people who are not aware of that language-addition.
If it is visible like in your last example then what happens is obvious.
So my point is:
I personally have the choice to avoid that problem, but others might choose to write code that does use this specifier. Therefore not having the option to put async at end of method declaration is IMO safer and more maintainable. (the alternative you showed is fine)
Thanks,
Maël.
November 21st, 2008 at 12:44 pm
I wonder how I can leave one procesor unloaded when I use async calls