Changes from Version 1 of OOXL

Author:

trac (IP: 127.0.0.1)

Timestamp:

08/29/2006 10:15:33 PM (4 years ago)

Comment:

--

OOXL

@@ +1 @@
+Example "class":
+
+{{{
+module Example;
+
+thread watcher(self) =
+  begin
+    lock self.mutex do
+      wait self.signal, self.mutex;
+      :$Signaled.$
+    end; 
+  end watcher;
+
+var
+  T: array const := {
+    "watcher" := watcher
+  };
+
+begin
+end Example.
+}}}
+
+As XL procedures are procedures __or__ threads, depending on keyword used, so are XL methods. Above example illustrates this.
+
+Client code for this example:
+
+{{{
+module Test;
+
+import
+  Example;
+
+proc Main() =
+  var
+    e := clone(Example.T);
+    i;
+  begin
+    e.watcher();
+
+    for i:=1 to 3 do
+      delay(1);
+      signal e.signal;
+      delay(1);
+    end;
+  end Main;
+
+begin
+end Test.
+}}}
+
+Inheritance is single, but it will be multiple if rationale found. It is done like this:
+
+{{{
+module Inherited;
+
+proc another(self) =
+  begin
+    :...
+  end another;
+
+var
+  T: array const := Example.T + {
+    "another" := another
+  };
+
+begin
+end Inherited.
+
+}}}
+
+As all of this is prototype based, methods with same name in supertype (Example.T) would not be overriden with above syntax. To override them, one will use:
+
+{{{
+var
+  T: array const := {
+    "another" := another
+  } + Example.T;
+}}}
+
+Few things are on wish-list for now. First, some syntax sugar for object declarations. Right now, we use ''array const'' to store our prototype in and it works, with it's limitiations.
+
+Runtime object of another order is needed here, and it is right place to introduce some ''XLClass'' object, to store "class" data into. New object mandates new syntax, maybe one where content is given by XLVarList, like:
+
+{{{
+module Render;
+
+class
+  T = Render.T {
+    id: text;
+    attrs: array := {};
+  } methods {
+    traverse();
+    print();
+  };
+}}}
+
+Currently, only type system present in XL runtime is Modula-3 one, used through [source:trunk/m3/xl/src/modules/XLModuleRTI.m3 RTI]. Another type system we evaluate for ''in vivo'' integration is Gtk 2.x [http://developer.gnome.org/doc/API/2.0/gobject/ch02.html The Glib Dynamic Type System]. 
+
+Emerging XL type system will mostly be aligned towards Modula-3 system, but Glib's is not to be ignored. It would be a boon to fully integrate emerging XL type system with existing Modula-3 and Glib systems. We can inherit multiple object types, even Modula-3/Glib mix. But, for obvious reasons, only one runtime layout can be used and that only for classes with single inheritance. Currently, with [source:trunk/m3/xl/src/modules/XLModuleRTI.m3 RTI] fully enabling read/write access to Modula-3 objects and plans to dynamically add/remove new object types to Modula-3 runtime, Modula-3 runtime layout is clear choice.