Monday, October 15, 2012

What's cooking in the EDT kitchen? - October 15

We continue making good progress towards our next milestone.

  • We're close to getting our system types compiled under the new extensible framework.  Once this is done we'll start merging the extensibility changes into the main code stream (and our nightly builds).
  • Started implementing classes.
  • We decided that "abstract" functions will be allowed in a class. An abstract function contains no statements and is terminated by a semicolon instead of the end keyword. In order for our parser to understand this new syntax, we will remove support for the do-nothing statement that consists of only a semicolon.
  • We revised the rules for comparisons involving the bytes type. Our old rule was that both bytes value must have a length, and the lengths must be the same. So you couldn't compare a bytes(3) to a bytes(4), or a bytes(3) to a bytes with no length. These comparisons are now valid. Comparing bytes(n) and bytes will be like comparing string(n) and string.


  1. "We decided that "abstract" functions will be allowed in a class."

    I've read all the planning notes but not clear on this. Can you tell me more? Specifically, are we talking about using "class" as an EGL keyword or type? You've spoken of single-level inheritance in the past ... is this where this comes into play for EGL? What sort of syntax are you looking at? Does the Java concept carry over ... if a class has an abstract method (function) then the class must be abstract too?

    As usual, you've piqued my curiosity with your mention of things that sound like OO.


  2. OK, here goes...this is subject to change but it's the direction we're heading in right now.

    Class will be a kind of part. A class can contain fields and functions (like a handler) but it can also implement interfaces and extend other classes. As in Java, we'll allow only one superclass. If a class contains an abstract method, or it implements an interface but doesn't contain all of the functions from the interface, the class is abstract and it can't be instantiated. Fields and functions of a class may be declared private, meaning they can't be used outside of the class itself.

    class A
    x string = "field in A";
    function f1() returns(string)
    return("hello from A's f1");
    function f2() returns(string)
    return("hello from A's f2");
    function f3() returns(string); // abstract

    interface I
    function iFunc() returns(string);

    class B extends A implements I
    // Override function from superclass.
    function f2() returns(string)
    return("hello from B's f2");

    // Implement abstract function from superclass.
    function f3() returns(string)
    return("hello from B's f3");

    // Implement function from interface I.
    function iFunc() returns(string)
    // Use function and field from superclass.
    return(f1() :: x);

  3. Sorry about the formatting. All my indenting disappeared when I saved my reply.

  4. I may have missed this in the planning documents but this takes EGL a lot farther down the OO road than I realized. Wow. Can you tell me a little more about what led the team to go this direction? Will the use of classes and inheritance play a central role in developing EGL apps going forward (using Rich UI, for example) or is this capability meant to address potential needs in future, heretofore unknown, generation targets?

    I love it but it does represent a significant departure from the EGL of old.



  5. Dan, you didn't miss it in the planning documents. It hasn't been very well communicated so far. We do have a few bugzillas related to classes, but I see that we need a few more. I'll take care of that in a moment. And I hope to have a more complete description of classes on the wiki soon.

    I hope no one is worried by the introduction of classes and inheritance. They'll be another tool you can use to develop your applications, if it makes sense for you. OO programming won't be mandatory. It's similar to C++, where every C program is also valid in C++. Also, while the class type is new to EDT, the concepts behind it are not: Services have already been implementing Interfaces, and ExternalTypes have already been extending other ExternalTypes.

    We aren't planning to change the things you've been using (records, handlers, widgets, etc.) into classes.

    So, why are we adding classes? There are many reasons. As you wrote, they may make it easier for us to target new languages and/or platforms in the future. Secondly, OO programming has proven to be successful, useful, and popular. To not offer it places limits on our users and the size of the EDT community. Another reason is that it opens the door for migrations to EGL from OO languages.


  6. Sounds to me like the best of all possible worlds. The things we're used to doing in EGL that lend themselves to an easy-to-code procedural approach stay that way and we gain the ability to use OO where and when it makes sense to do so. I have a Java background and have missed having OO constructs in EGL so I welcome this direction. It may put some people unfamiliar with OO off until they realize that, as you point out, they have already been introduced to some of the concepts through other EGL constructs.

    Mel Beckman, one of the old guard in the RPG world, recently wrote a controversial opinion piece about the demise of RPG. ( He wrote that "the most important single modern language attribute" needed to revive RPG is "object orientation with inheritance". Reading his article I couldn't help but reflect on EGL and think that it, like RPG, was limited in some important ways by the lack of OO. I couldn't be happier to hear that EGL is gaining OO but not losing the existing constructs that make it so easy to rapidly develop business applications.

  7. The post is telling about what is cooking in edt kitchen. Know the details from the post
    Team cooking classes
    Team Building Brisbane