tag:blogger.com,1999:blog-2660857613420302960.post8309774384616197635..comments2024-03-01T03:28:13.083-05:00Comments on The Official Eclipse EDT Team Blog: What's cooking in the EDT kitchen? - October 15Xegl Teamhttp://www.blogger.com/profile/16028710936748007825noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-2660857613420302960.post-90754745331030915662012-11-09T02:24:30.209-05:002012-11-09T02:24:30.209-05:00The post is telling about what is cooking in edt k...The post is telling about what is cooking in edt kitchen. Know the details from the post<br /><a href="http://www.superteams.com.au/corporate-master-chef" rel="nofollow">Team cooking classes</a><br /><a href="http://www.superteams.com.au/" rel="nofollow">Team Building Brisbane</a><br /><br /><br />Daniel Anthonyhttps://www.blogger.com/profile/02608472916563989268noreply@blogger.comtag:blogger.com,1999:blog-2660857613420302960.post-43513595619054242992012-10-18T12:09:24.854-04:002012-10-18T12:09:24.854-04:00Sounds to me like the best of all possible worlds....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.<br /><br />Mel Beckman, one of the old guard in the RPG world, recently wrote a controversial opinion piece about the demise of RPG. (http://www.iprodeveloper.com/article/opinion/is-rpg-dead-699217) 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.Danhttps://www.blogger.com/profile/04754348598098569863noreply@blogger.comtag:blogger.com,1999:blog-2660857613420302960.post-10947281472991979012012-10-18T09:48:56.868-04:002012-10-18T09:48:56.868-04:00Dan, you didn't miss it in the planning docume...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.<br /><br />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.<br /><br />We aren't planning to change the things you've been using (records, handlers, widgets, etc.) into classes.<br /><br />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.<br /><br />MattMatt Heitzhttps://www.blogger.com/profile/03044786937973887004noreply@blogger.comtag:blogger.com,1999:blog-2660857613420302960.post-38998658535719631362012-10-17T12:58:37.315-04:002012-10-17T12:58:37.315-04:00I may have missed this in the planning documents b...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?<br /><br />I love it but it does represent a significant departure from the EGL of old. <br /><br />Thanks,<br /><br />Dan<br />Danhttps://www.blogger.com/profile/04754348598098569863noreply@blogger.comtag:blogger.com,1999:blog-2660857613420302960.post-35603074023450877502012-10-17T09:10:39.471-04:002012-10-17T09:10:39.471-04:00Sorry about the formatting. All my indenting disa...Sorry about the formatting. All my indenting disappeared when I saved my reply.Matt Heitzhttps://www.blogger.com/profile/03044786937973887004noreply@blogger.comtag:blogger.com,1999:blog-2660857613420302960.post-70839350054291572552012-10-17T09:09:36.472-04:002012-10-17T09:09:36.472-04:00OK, here goes...this is subject to change but it&#...OK, here goes...this is subject to change but it's the direction we're heading in right now.<br /><br />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.<br /><br />class A<br /> x string = "field in A";<br /> function f1() returns(string)<br /> return("hello from A's f1");<br /> end<br /> function f2() returns(string)<br /> return("hello from A's f2");<br /> end<br /> function f3() returns(string); // abstract<br />end<br /><br />interface I<br /> function iFunc() returns(string);<br />end<br /><br />class B extends A implements I<br /> // Override function from superclass.<br /> function f2() returns(string)<br /> return("hello from B's f2");<br /> end<br /><br /> // Implement abstract function from superclass.<br /> function f3() returns(string)<br /> return("hello from B's f3");<br /> end<br /><br /> // Implement function from interface I.<br /> function iFunc() returns(string)<br /> // Use function and field from superclass.<br /> return(f1() :: x);<br /> end<br />endMatt Heitzhttps://www.blogger.com/profile/03044786937973887004noreply@blogger.comtag:blogger.com,1999:blog-2660857613420302960.post-61788951584347291622012-10-16T13:08:59.573-04:002012-10-16T13:08:59.573-04:00"We decided that "abstract" functio..."We decided that "abstract" functions will be allowed in a class."<br /><br />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?<br /><br />As usual, you've piqued my curiosity with your mention of things that sound like OO.<br /><br />--DanDanhttps://www.blogger.com/profile/04754348598098569863noreply@blogger.com