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.

  • Variable everywhere and create a instance at the same time you declare.
  • 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;

  • Properties - implict read and write, declare only when necessary
  • property ContactID : Integer;
    property FirstName : String;
    property Email : String;
    property ModifiedDate : DateTime;

  • String support in case statements
  • case l_action of
        ‘logout’: begin
                       …
                  end;

    ‘login’: begin
                       …
             end;
    else begin
              …
           end;
    end;

  • Main method - Entry point for that executable
  •  

    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;


  • Asynchronous statements - makes it possible to execute one or more statements asynchronously from the method in which they are defined. Implementation depends on whether the PFX framework is referenced. If so, Async statements are run via the PFX framework as a task, else they are added to the .NET thread pool.
  • Asynchronous statements

    Result is:

    Stay tuned, you can do much more with Delphi Prism.

    Posted by Andreano Lanusse on November 19th, 2008 under Delphi, English |



    7 Responses to “Delphi Prism Language - What you can do”

    1. Maël Hörz Says:

      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.

    2. Maël Hörz Says:

      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.

    3. Andreano Lanusse Says:

      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();

    4. Dennis Says:

      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!

    5. Marcelo Says:

      Hi Andreano,

      Very nice.
      Any plans to include these new languege features in the Delphi/CB Win32 Compiler?

      Thanks

    6. Maël Hörz Says:

      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.

    7. Masha Petrova Says:

      I wonder how I can leave one procesor unloaded when I use async calls

    Leave a Comment


    Server Response from: blogs2.codegear.com

     
    © Copyright 2008 Embarcadero Technologies, Inc. All Rights Reserved. Contact Us  |   Site Map  |   Legal Notices  |   Privacy Policy  |   Report Software Piracy