[Oorexx-devel] object, class, metaclass... Big picture ?
I try to understand the underlying model for object, class, metaclass (source excerpt at the end of the mail). Not easy... I can't find a suitable definition for the ??? below. Extracted from rexxref : 5.1.1 The Object class is the root of the class hierarchy. The instance methods of the Object class are, therefore, available on all objects. [JLF] The class methods of the Object class are ??? 5.1.2 The Class class is like a factory that produces the factories that produce objects. It is a subclass of the Object class. The instance methods of the Class class are also the class methods of all classes. [JLF] The class methods of the Class class are ??? 4.1.4 A metaclass is a class you can use to create another class. The only metaclass that Rexx provides is .Class, the Class class. The Class class is the metaclass of all the classes Rexx provides. This means that instances of .Class are themselves classes. [JLF] The instance methods of a metaclass are ??? : [proposition] the class methods of all the classes associated to this metaclass. [JLF] The class methods of a metaclass are ??? What is a scope ? (I see scopes and metaClassScopes in the source excerpt). Is there any publication that gives a big picture of this data model ? In particular, I try to put in words the actions done by these methods : ~instanceMethods ~methods ~send Source excerpt : ObjectClass.hpp class RexxInternalObject : public RexxVirtualBase{ inline RexxBehaviour *getObjectType() { return behaviour; } - RexxBehaviour *behaviour; /* the object's behaviour */ class RexxObject : public RexxInternalObject { inline RexxBehaviour *behaviourObject() { return this-behaviour; } RexxBehavious.hpp class RexxBehaviour : public RexxInternalObject { inline RexxTable *getMethodDictionary() { return this-methodDictionary; }; RexxIdentityTable *scopes; /* scopes table */ RexxTable *methodDictionary; /* method dictionary */ RexxClass *owningClass;/* class that created this object */ RexxTable *instanceMethodDictionary; /* methods added via SETMETHOD */ ClassClass.hpp class RexxClass : public RexxObject { RexxTable *classMethodDictionary; // class methods specific to this class RexxBehaviour *instanceBehaviour; // instances of this class inherit this behaviour RexxTable *instanceMethodDictionary; // methods added to this class - RexxClass *baseClass; // Baseclass of this class RexxArray *metaClass; // Metaclass of this class RexxArray *metaClassMethodDictionary; // Metaclass mdict RexxIdentityTable *metaClassScopes; // Metaclass scopes - RexxArray *classSuperClasses; // The superclass and any inherited mixins for class behaviour RexxArray *instanceSuperClasses; // The superclass and any inherited mixins for instance behaviour - RexxList *subClasses; // our list of weak referenced subclasses Jean Louis -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] object, class, metaclass... Big picture ?
Hi Jean-Louis, it seems that Rick is currently not online, so I try to give some shots, hoping they may help a little bit. [One problem in OO is the terminology, which sometimes comes into ones way (instead of clarifying concepts, sometimes they obfuscate them, unfortunately). There are quite a few synonyms, like object == instance == value etc. or class == type etc.] On 08.08.2011 10:23, Jean-Louis Faucher wrote: I try to understand the underlying model for object, class, metaclass (source excerpt at the end of the mail). Not easy... ooRexx has been quite influenced by Smalltalk, so some of the concepts are directly from there. In general there are no class methods! (This means among other things that all methods are instance methods!) :) --- * There is simply a class that allows one to define methods and attributes the methods of a class can have direct access to. o A 'method is a function/procedure that is only available for instances of the class in which the methods are defined. * An object is just an instance of a class. The object possesses the functionality/behaviour of the methods of its class. * There is a class hierarchy which is used when method resolution takes place with the concept that all methods (not attributes!) of all the superclasses (shortest path to root class) get inherited. (This is also the area where scope becomes important w.r.t. method resolution, but also access to attributes, i.e. concurrency issues and the like.) o The class hierarchy allows an object to have more methods (functionality/behaviour) than defined in its own class, by means of inheritance. * The root of a class hierarchy is usually calld Object, which is a class, as it defines methods. As all other classes in ooRexx are derived directly (by default) or indirectly from this root class, its methods (functionality/behaviour) is inherited by all other classes (and its instances)! --- In dynamic languages the class definitions (the name, the methods) are represented in objects as well. The class used for creating objects that keep the definition of a class in ooRexx (and many other languages) is called Class. As instances of this class describe the structure and behaviour of individual classes the term metaclass is used for it. So the ooRexx class Class is the metaclass of ooRexx. Of course, if one subclasses Class it inherits all abilities of Class and as such keeps on being able to maintain the definition of classes. An instance of Class or one of its subclasses (hence of any metaclass) is called class object. The instance methods of metaclasses (i.e. class objects) are called class methods, indicating that these methods belong to the class object. --- When ooRexx starts up the class hierarchy is created in native code and from the image. I.e. all ooRexx supplied classes build (and are represented in) the ooRexx class hierarchy in the form of class objects. Each of these class objects maintains e.g. the name of the class and the methods, instances of this class should get assigned to at creation time (which is done in the 'new' method of Class). At runtime one can access these class objects with their environment symbol, which is the name of the class preceeded by a dot, e.g.: .object, .class, .array and the like. --- One speciality (and very powerful feature) of ooRexx is its ability to add/remove methods from instances (one-off-objects)! Cf. e.g. the Object's methods setMethod and unsetMethod, but also the Class method enhanced to create instances of a class which get additional methods (hence one-off). It is also possible to change the set of methods instances of a class get assigned to, when they get created. Cf. the Class methods method, methods, define and delete, which allow to maintain the methods instances of a class should get assigned to at the time they got created. Note: the method instanceMethod and instanceMethods in the root class Object allow one to fetch the actual instance method(s) of an object (ie. also from one-off objects). --- Finally ad methods of a class object: all methods of a class object are instance methods, sometimes dubbed class methods, because they are the instance methods of a metclass/class object. A class object is just a normal ooRexx object and as such it is possible to add/remove instance methods to/from it! When an ooRexx class defines methods with the subkeyword class then these methods will be added to the class object (as instance methods of the class object). --- Hope that helps clarify a few of your questions. Ad ooRexx native code and implementation, this is something that probably Rick is the only one who can answer at the moment. ---rony I can't find a suitable definition for the ??? below. Extracted from rexxref : 5.1.1 The Object class is the root of the class hierarchy. The instance methods
Re: [Oorexx-devel] object, class, metaclass... Big picture ?
Hi Jean-Louis, overlooked the send question: in ooRexx the defined methods and the messages (represented by the tilde/twiddle/~) are represented in their own ooRexx classes. So if in a Rexx program the ~ is encountered a message object (an instance of the class Message) is created. However, the creation of a message does not yet cause that message to be dispatched to the object. In order to dispatch a message object (which actually carries out the message) one has to send it either the mssage send or start. * Using the send method causes the execution to halt until the message has been carried out in full and allows one to fetch directly a result value, if any. * Using the start method cuases the execution to go on, the message is carried out concurrently and returns an object, which can be interrogated for the status of the asynchroneous execution of the started message. Eventually, when the asynchroneous message finished, one can learn that and even fetch the result. Cf. the reference documentation of the class Message. HTH, ---rony On 08.08.2011 11:39, Rony G. Flatscher wrote: Hi Jean-Louis, it seems that Rick is currently not online, so I try to give some shots, hoping they may help a little bit. [One problem in OO is the terminology, which sometimes comes into ones way (instead of clarifying concepts, sometimes they obfuscate them, unfortunately). There are quite a few synonyms, like object == instance == value etc. or class == type etc.] On 08.08.2011 10:23, Jean-Louis Faucher wrote: I try to understand the underlying model for object, class, metaclass (source excerpt at the end of the mail). Not easy... ooRexx has been quite influenced by Smalltalk, so some of the concepts are directly from there. In general there are no class methods! (This means among other things that all methods are instance methods!) :) --- * There is simply a class that allows one to define methods and attributes the methods of a class can have direct access to. o A 'method is a function/procedure that is only available for instances of the class in which the methods are defined. * An object is just an instance of a class. The object possesses the functionality/behaviour of the methods of its class. * There is a class hierarchy which is used when method resolution takes place with the concept that all methods (not attributes!) of all the superclasses (shortest path to root class) get inherited. (This is also the area where scope becomes important w.r.t. method resolution, but also access to attributes, i.e. concurrency issues and the like.) o The class hierarchy allows an object to have more methods (functionality/behaviour) than defined in its own class, by means of inheritance. * The root of a class hierarchy is usually calld Object, which is a class, as it defines methods. As all other classes in ooRexx are derived directly (by default) or indirectly from this root class, its methods (functionality/behaviour) is inherited by all other classes (and its instances)! --- In dynamic languages the class definitions (the name, the methods) are represented in objects as well. The class used for creating objects that keep the definition of a class in ooRexx (and many other languages) is called Class. As instances of this class describe the structure and behaviour of individual classes the term metaclass is used for it. So the ooRexx class Class is the metaclass of ooRexx. Of course, if one subclasses Class it inherits all abilities of Class and as such keeps on being able to maintain the definition of classes. An instance of Class or one of its subclasses (hence of any metaclass) is called class object. The instance methods of metaclasses (i.e. class objects) are called class methods, indicating that these methods belong to the class object. --- When ooRexx starts up the class hierarchy is created in native code and from the image. I.e. all ooRexx supplied classes build (and are represented in) the ooRexx class hierarchy in the form of class objects. Each of these class objects maintains e.g. the name of the class and the methods, instances of this class should get assigned to at creation time (which is done in the 'new' method of Class). At runtime one can access these class objects with their environment symbol, which is the name of the class preceeded by a dot, e.g.: .object, .class, .array and the like. --- One speciality (and very powerful feature) of ooRexx is its ability to add/remove methods from instances (one-off-objects)! Cf. e.g. the Object's methods setMethod and unsetMethod, but also the Class method enhanced to create instances of a class which get additional methods (hence one-off). It is also possible to change the set of methods instances of a
Re: [Oorexx-devel] object, class, metaclass... Big picture ?
Thanks a lot Rony ! About ~send, I was focusing on the search order for method selection, and I found the answer in rexxref 4.2.5. There is no reference to metaclass there, so I assume that the methods of a metaclass are not visible from an object. Honestly, I can't say it's still very clear for the distinction class/metaclass. I thought that a metaclass was the class of a class, but this is not the case in the internal model. (All the details in the attached file...) RexxClass is a RexxObject. As such, it inherits the attribute 'behaviour' which is used for : ~class, ~instanceMethod, ~instanceMethods, ~setMethod, ~unsetMethod Though this behaviour, I can get the class of a RexxClass. But RexxClass has also an attribute 'metaClass' which is an array of RexxClass. The other attributes for which it's not clear are : scopes classMethodDictionary (~!DEFINE_CLASS_METHOD) metaClassMethodDictionary metaClassScopes Jean-Louis 2011/8/8 Rony G. Flatscher rony.flatsc...@wu-wien.ac.at ** Hi Jean-Louis, overlooked the send question: in ooRexx the defined methods and the messages (represented by the tilde/twiddle/~) are represented in their own ooRexx classes. So if in a Rexx program the ~ is encountered a message object (an instance of the class Message) is created. However, the creation of a message does not yet cause that message to be dispatched to the object. In order to dispatch a message object (which actually carries out the message) one has to send it either the mssage send or start. - Using the send method causes the execution to halt until the message has been carried out in full and allows one to fetch directly a result value, if any. - Using the start method cuases the execution to go on, the message is carried out concurrently and returns an object, which can be interrogated for the status of the asynchroneous execution of the started message. Eventually, when the asynchroneous message finished, one can learn that and even fetch the result. Cf. the reference documentation of the class Message. HTH, ---rony On 08.08.2011 11:39, Rony G. Flatscher wrote: Hi Jean-Louis, it seems that Rick is currently not online, so I try to give some shots, hoping they may help a little bit. [One problem in OO is the terminology, which sometimes comes into ones way (instead of clarifying concepts, sometimes they obfuscate them, unfortunately). There are quite a few synonyms, like object == instance == value etc. or class == type etc.] On 08.08.2011 10:23, Jean-Louis Faucher wrote: I try to understand the underlying model for object, class, metaclass (source excerpt at the end of the mail). Not easy... ooRexx has been quite influenced by Smalltalk, so some of the concepts are directly from there. In general there are no class methods! (This means among other things that all methods are instance methods!) :) --- - There is simply a class that allows one to define methods and attributes the methods of a class can have direct access to. - A 'method is a function/procedure that is only available for instances of the class in which the methods are defined. - An object is just an instance of a class. The object possesses the functionality/behaviour of the methods of its class. - There is a class hierarchy which is used when method resolution takes place with the concept that all methods (not attributes!) of all the superclasses (shortest path to root class) get inherited. (This is also the area where scope becomes important w.r.t. method resolution, but also access to attributes, i.e. concurrency issues and the like.) - The class hierarchy allows an object to have more methods (functionality/behaviour) than defined in its own class, by means of inheritance. - The root of a class hierarchy is usually calld Object, which is a class, as it defines methods. As all other classes in ooRexx are derived directly (by default) or indirectly from this root class, its methods (functionality/behaviour) is inherited by all other classes (and its instances)! --- In dynamic languages the class definitions (the name, the methods) are represented in objects as well. The class used for creating objects that keep the definition of a class in ooRexx (and many other languages) is called Class. As instances of this class describe the structure and behaviour of individual classes the term metaclass is used for it. So the ooRexx class Class is the metaclass of ooRexx. Of course, if one subclasses Class it inherits all abilities of Class and as such keeps on being able to maintain the definition of classes. An instance of Class or one of its subclasses (hence of any metaclass) is called class object. The instance methods of metaclasses (i.e. class objects) are called class methods, indicating that these methods belong to the class object. --- When ooRexx
Re: [Oorexx-devel] object, class, metaclass... Big picture ?
Hi Jean-Louis, On 08.08.2011 14:40, Jean-Louis Faucher wrote: About ~send, I was focusing on the search order for method selection, and I found the answer in rexxref 4.2.5. There is no reference to metaclass there, so I assume that the methods of a metaclass are not visible from an object. No, they are not! (Unlike in C++ or Java or the like.) If one needs to get at the class methods in ooRexx one first needs to get at the class object (which created the object in question) by sending the message class to the object in question. Then you can send the names of the class methods to the class object that the message class returned. (Again, the class object is just a plain object, so all rules about objects apply.) Honestly, I can't say it's still very clear for the distinction class/metaclass. I thought that a metaclass was the class of a class, but this is not the case in the internal model. This depends on your definition of class of a class, class and metaclass, for which you seem to expect a distinction to be present. There is none in ooRexx. A metaclass is a plain class, i.e. it allows one to define methods that are regarded to belong together to serve some purpose. The term meta just points at the usage of a particular class, usually named Class: this class allows one to define, maintain and interrogate the methods of classes at runtime. But the mechanics (allowing to define methods and sending messages) are the same as for any other class: one can create instances, send the names of existing methods, etc. The metaclass also has a method defined to create an instance/object/value of the class (possessing all methods that were defined at object creation time and which can be retrieved from the metaclass with the message methods) and after initialization returns it: the method new. Maybe a different application/point-of-view: every time an ooRexx program is processed the ::class-directive will cause the runtime system to create an instance of Class assigning that instance (a class object) the name found with the class directive. Then, for each ::method-directive an instance of the class Method is created by the found name, which also stores the Rexx code; that method object is then added to the class object collection of methods that should be assigned to objects it creates, using the class object method define. In the case that a ::method-directive has the subkeyword class that method is added directly to the class object instead using the Object's method setMethod. (The major distraction, I think, stems from the metaphysically sounding name metaclass, as if something special, secret is allotted to it.) The speciality of the class named Class is simply: it allows for maintaining the name of an ooRexx class, define/delete methods that instances of an ooRexx class should be assigned to an object, when it gets created. That's it. (Maybe, if you state what you think a class of a class is/should be about, then we could discuss those concepts/expectations in more detail.) --- Ad implementation details/rationales/structures/mechanics, again, only Rick can explain them. (All the details in the attached file...) RexxClass is a RexxObject. As such, it inherits the attribute 'behaviour' which is used for : ~class, ~instanceMethod, ~instanceMethods, ~setMethod, ~unsetMethod Though this behaviour, I can get the class of a RexxClass. Yes, these are available by inheritance, they are not locally defined in the class object for RexxClass! But RexxClass has also an attribute 'metaClass' which is an array of RexxClass. metaClass is an instance method of the class object, defined in RexxClass (along with e.g. define, delete. enhanced, new, superclasses, subclasses, etc.). Not sure why it is backed by an array in the implementation (Rick would know, as he implemented it that way). The other attributes for which it's not clear are : scopes A scope generally defines the visibility of variables, labels. In the context of ooRexx it also defines the visibility of routines and classes, e.g. routines and classes are always seen/accessible in the program that defined them. Public routines and classes become visible once the program was called/required that defined them. In the context of methods there is one important item in addition: access to attributes! Usually all methods that are defined for a class share the same scope, i.e. if they define attributes (using the EXPOSE-statement as the first instruction) then they are shared/visible among all methods. Accessing attributes in parallel running/executing methods would incur the classic problems, hence access to attributes are guarded in ooRexx by default. Now, it is possible in ooRexx to define methods in a program that are not assignable to a specific class, because the method directives preceed class-directives. Such floating methods get collected by the interpreter and from the defining program one can access them via the .methods environment
[Oorexx-devel] Explicitly listed methods, multiple inheritance possible with metaclasses as well (Re: object, class, metaclass... Big picture ?
Hi Jean-Louis, totally overlooked your original questions related to the reference documentations: On 08.08.2011 10:23, Jean-Louis Faucher wrote: I can't find a suitable definition for the ??? below. Extracted from rexxref : 5.1.1 The Object class is the root of the class hierarchy. The instance methods of the Object class are, therefore, available on all objects. [JLF] The class methods of the Object class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 5.1.2 The Class class is like a factory that produces the factories that produce objects. It is a subclass of the Object class. The instance methods of the Class class are also the class methods of all classes. [JLF] The class methods of the Class class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 4.1.4 A metaclass is a class you can use to create another class. The only metaclass that Rexx provides is .Class, the Class class. The Class class is the metaclass of all the classes Rexx provides. This means that instances of .Class are themselves classes. [JLF] The instance methods of a metaclass are ??? : [proposition] the class methods of all the classes associated to this metaclass. All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- If you think about a metaclass you defined yourself, that needs to be a subclass of .Class, then: All methods you defined. Plus all methods of all superclasses, among them all instance methods of the class Class via inheritance: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. [JLF] The class methods of a metaclass are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- If you think about a metaclass you defined yourself, that needs to be a subclass of .Class, then: All methods you defined with the subkeyword class. Plus all class methods of all superclasses, among them all methods of the class Class via inheritance: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- You could look at the methods interactively, e.g. with rgf_util2.rgf in rexxtry sessions resp. your shell: call rgf_util2.rex call dump2 .class~methods -- lists all methods defined for instances of the class Class, includes inherited methods call dump2 .class~methods(.class) -- lists all methods defined for instances of the class Class only call dump2 .class~methods(.object) -- lists all methods defined for instances of the class Object only call dump2 .class~instanceMethods -- lists all instance methods defined for the class Class, includes inherited methods call dump2 .class~instanceMethods(.class) -- lists all instance methods defined for the class Class only call dump2 .class~instanceMethods(.object) -- lists all instance methods defined for the class Object only ... If you then compare the methods for the Class class object with those that instances of that class will get, you will notice that the Class class object instance has the method NEW in addition. (It is missing from the Class methods collection of methods to give to instances. It seems that the NEW method gets added via setMethod while the class objects get created.) Not sure, why this got implemented this way, but Rick would know. --- Also a final remark ad metaclasses: as they are normal ooRexx classes it is possible to employ multiple inheritance among metaclasses which opens a lot of interesting and powerful problem solution
Re: [Oorexx-devel] Explicitly listed methods, multiple inheritance possible with metaclasses as well (Re: object, class, metaclass... Big picture ?
Rony, Thanks again for this overview. In fact, in place of the ???, I was searching for a sentence which explains the impacts (or consequences), like it's done for the instance methods below : 5.1.1 The Object class is the root of the class hierarchy. The instance methods of the Object class are, therefore, available on all objects. [JLF] The class methods of the Object class are ??? a sentence which summarizes the impacts. I try to make a mental model of ooRexx internals... Something that would be similar to : http://www.iam.unibe.ch/~ducasse/Teaching/Archives/STOBJ/allPapers.pdf See section 2 The ObjVlisp model on 3rd page. There is a set of definitions, and I just try to write similar postulates for ooRexx... I can't say that I understand all the subtleties of ObjVlisp :-) And the situation is currently the same for ooRexx, but trying to describe in plain words the ooRexx model should help me to understand better. Jean Louis 2011/8/8 Rony G. Flatscher rony.flatsc...@wu-wien.ac.at ** Hi Jean-Louis, totally overlooked your original questions related to the reference documentations: On 08.08.2011 10:23, Jean-Louis Faucher wrote: I can't find a suitable definition for the ??? below. Extracted from rexxref : 5.1.1 The Object class is the root of the class hierarchy. The instance methods of the Object class are, therefore, available on all objects. [JLF] The class methods of the Object class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 5.1.2 The Class class is like a factory that produces the factories that produce objects. It is a subclass of the Object class. The instance methods of the Class class are also the class methods of all classes. [JLF] The class methods of the Class class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 4.1.4 A metaclass is a class you can use to create another class. The only metaclass that Rexx provides is .Class, the Class class. The Class class is the metaclass of all the classes Rexx provides. This means that instances of .Class are themselves classes. [JLF] The instance methods of a metaclass are ??? : [proposition] the class methods of all the classes associated to this metaclass. All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- If you think about a metaclass you defined yourself, that needs to be a subclass of .Class, then: All methods you defined. Plus all methods of all superclasses, among them all instance methods of the class Class via inheritance: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. [JLF] The class methods of a metaclass are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- If you think about a metaclass you defined yourself, that needs to be a subclass of .Class, then: All methods you defined with the subkeyword class. Plus all class methods of all superclasses, among them all methods of the class Class via inheritance: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- You could look at the methods interactively, e.g. with rgf_util2.rgf in rexxtry sessions resp. your shell: call rgf_util2.rex call dump2 .class~methods -- lists all methods defined for instances of the class Class, includes inherited methods call dump2 .class~methods(.class) -- lists all methods defined for instances of the class Class only call dump2 .class~methods(.object) -- lists all methods defined for
Re: [Oorexx-devel] Explicitly listed methods, multiple inheritance possible with metaclasses as well (Re: object, class, metaclass... Big picture ?
A metaclass has one very important distinction: The NEW method of a metaclass MUST return a class object, not some other sort of object. It is a factory for making class objects used to build new classes. The processing goes something like this: 1) Send a NEW message to the metaclass to create a new class object instance. This object will implement some number of methods directly just be virtue of being an object. These are the class object's instance methods, but since it is a class object, they are frequently referred to as class methods. It also has an internal dictionary which are the methods that will be given to its instances when they are created. These are the methods that are frequently referred to as instance methods. Typically, the metaclass is just the Class class. 2) Give the two dictionaries above (I'll refer to them as the class method dictionary and the instance method dictionary from here on), a merging process then takes place to create the new class object. Each of these dictionaries are merged with the following: a) The class and instance method dictionaries from the superclass. b) The class and instance method dictionaries from each of the inherited mixin classes c) The additional methods defined by the directories. The methods tagged with the CLASS keyword are added to the class dictionary, the regular methods are added to the instance dictionary. A lot of the metaclass processing was driven by the since removed SOM support. On an import, a SOM metaclass object was used to retrieve the methods associated with the imported SOM class. I believe that the SOM support was the reason the metaclasses array exists. I think the SOM object model allowed for multiple metaclasses. It has been a long time and I never was directly involved with the SOM support in the first place. Contrary to Rony's assertions, I was not the original implementer of this particular bit of code. One of the few portions of the runtime where this isn't the case. I generally find I have to carefully read through what's going on every time I need to touch that area, and there are a few things I found a bit strange about it, but have not had a good reason to do a major cleanup pass, particularly since this is an area that has tended to be pretty sensitive to changes. Rick On Mon, Aug 8, 2011 at 10:35 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Hi Jean-Louis, totally overlooked your original questions related to the reference documentations: On 08.08.2011 10:23, Jean-Louis Faucher wrote: I can't find a suitable definition for the ??? below. Extracted from rexxref : 5.1.1 The Object class is the root of the class hierarchy. The instance methods of the Object class are, therefore, available on all objects. [JLF] The class methods of the Object class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 5.1.2 The Class class is like a factory that produces the factories that produce objects. It is a subclass of the Object class. The instance methods of the Class class are also the class methods of all classes. [JLF] The class methods of the Class class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 4.1.4 A metaclass is a class you can use to create another class. The only metaclass that Rexx provides is .Class, the Class class. The Class class is the metaclass of all the classes Rexx provides. This means that instances of .Class are themselves classes. [JLF] The instance methods of a metaclass are ??? : [proposition] the class methods of all the classes associated to this metaclass. All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- If you think about a metaclass you defined yourself, that needs to be a subclass of .Class, then: All methods you defined. Plus all methods of all superclasses, among them all instance methods of the class Class via inheritance: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all
Re: [Oorexx-devel] Explicitly listed methods, multiple inheritance possible with metaclasses as well (Re: object, class, metaclass... Big picture ?
Rick That's *exactly* what I was looking for ! Now I have to read that at least 10 times to make it enter in my mind :-). But that will help greatly to read the code. Jean-Louis 2011/8/8 Rick McGuire object.r...@gmail.com A metaclass has one very important distinction: The NEW method of a metaclass MUST return a class object, not some other sort of object. It is a factory for making class objects used to build new classes. The processing goes something like this: 1) Send a NEW message to the metaclass to create a new class object instance. This object will implement some number of methods directly just be virtue of being an object. These are the class object's instance methods, but since it is a class object, they are frequently referred to as class methods. It also has an internal dictionary which are the methods that will be given to its instances when they are created. These are the methods that are frequently referred to as instance methods. Typically, the metaclass is just the Class class. 2) Give the two dictionaries above (I'll refer to them as the class method dictionary and the instance method dictionary from here on), a merging process then takes place to create the new class object. Each of these dictionaries are merged with the following: a) The class and instance method dictionaries from the superclass. b) The class and instance method dictionaries from each of the inherited mixin classes c) The additional methods defined by the directories. The methods tagged with the CLASS keyword are added to the class dictionary, the regular methods are added to the instance dictionary. A lot of the metaclass processing was driven by the since removed SOM support. On an import, a SOM metaclass object was used to retrieve the methods associated with the imported SOM class. I believe that the SOM support was the reason the metaclasses array exists. I think the SOM object model allowed for multiple metaclasses. It has been a long time and I never was directly involved with the SOM support in the first place. Contrary to Rony's assertions, I was not the original implementer of this particular bit of code. One of the few portions of the runtime where this isn't the case. I generally find I have to carefully read through what's going on every time I need to touch that area, and there are a few things I found a bit strange about it, but have not had a good reason to do a major cleanup pass, particularly since this is an area that has tended to be pretty sensitive to changes. Rick On Mon, Aug 8, 2011 at 10:35 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Hi Jean-Louis, totally overlooked your original questions related to the reference documentations: On 08.08.2011 10:23, Jean-Louis Faucher wrote: I can't find a suitable definition for the ??? below. Extracted from rexxref : 5.1.1 The Object class is the root of the class hierarchy. The instance methods of the Object class are, therefore, available on all objects. [JLF] The class methods of the Object class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 5.1.2 The Class class is like a factory that produces the factories that produce objects. It is a subclass of the Object class. The instance methods of the Class class are also the class methods of all classes. [JLF] The class methods of the Class class are ??? All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. 4.1.4 A metaclass is a class you can use to create another class. The only metaclass that Rexx provides is .Class, the Class class. The Class class is the metaclass of all the classes Rexx provides. This means that instances of .Class are themselves classes. [JLF] The instance methods of a metaclass are ??? : [proposition] the class methods of all the classes associated to this metaclass. All methods of the class Class: =, \=, ==, \==, , , baseClass, defaultName, define, delete, enhanced, hashcode, id, inherit, isSubclassOf, metaClass, method, methods, mixinClass, new, queryMixinClass, subClass, subClasses, superClass, superClasses, uninherit. Plus all methods of the root class Object via inheritance. --- If you think about a metaclass you defined yourself, that needs to be a subclass of .Class, then: All methods you defined. Plus all methods of
[Oorexx-devel] Remove trailing whitespace before commits
Hi all, Although we haven't published any formal source code style guidelines and we don't enforce any coding style, committing code with trailing whitespace is particularly annoying to me. I haven't said anything in the past, because the problem has never really happened. When code is committed that has a lot of white space only changes it makes it hard to determine from the svn notice what has really changed. It makes it hard when using svn diff to tell exactly what the differences are. Any decent programmer's editor will have some option for stripping out trailing white space. If several of the developers use that option, as most of the current developers do, then the next time one of those developers makes a small change to the file, the trailing whitespace will be stripped out, producing another commit message where it is hard to spot the actual changes. The current code base contains no, or very very little, trailing whitespace. I would like to keep it that way. Which of course is why I'm posting this. grin Not trying to point a finger at any one, or be obnoxious about this, but if you look at the svn message for commit 7094, at the start of the ProductView.rex file you see 7 whitespace only changes: @@ -34,21 +34,26 @@ /* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /* */ /**/ -/* ooDialog User Guide - Exercise 04b: ProductView.rex - The ProductView component v00-02 28Jly11 - - Contains: classes ProductView and AboutDialog. +/* ooDialog User Guide + Exercise 04b: ProductView.rex - The ProductView component v00-03 06Aug11 + + Contains: classes ProductView and AboutDialog. Pre-requisites: ProductView.dll, ProductView.h. Support\NumberOnlyEditEx.cls (copied from ooDialog Samples) - - Description: A sample Product View component - part of the sample + + Description: A sample Product View component - part of the sample Order Management application. - + Outstanding Problems: None reported. - + The diff has 98 lines where the only change is whitespace added to the end of the line. Since this happens to be a file that I'm likely to edit, as soon as I save the file, there will be another large set of whitespace only changes. Then if I commit a small 1 line change, it will create a diff with 99 line changes. So, I'm sort of formally stating that I would like to see trailing whitespace stripped before any commit to the source code. If anyone is using a program editor where they don't know how to configure it to strip trailing white space on save, I'd be more than happy to research how to do it with that editor. Just let me know what the editor is. -- Mark Miesfeld -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Remove trailing whitespace before commits
On Mon, Aug 8, 2011 at 1:18 PM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: If a script would take automatically take care of stripping off whitespace, then no one is forced to configure his editor to do that automatically. AFAIK subversion/svn allows for defining hook scripts. It does allow hook scripts, but that is not much use here because it won't work well. Or is at least is advised against. Pre-commit hooks can only be used to prevent a transaction, they can not modify the transaction. A post-commit hook that removed the whitespace would then require a second commit. I've seen this advised against, although I guess that could come down to individual like or dislike. It would certainly leave the committer's file out of sync with the repository immediately after the commit. I personally would rather configure my editor than deal with that. grin Most cooperative projects I've looked at, require the programmer to conform to the style guidelines, if they have them, rather than changing code after it is committed. -- Mark Miesfeld -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Remove trailing whitespace before commits
Trailing white spaces happens with Jedit (I use it under Windows for XML files and rexx files). So I suppose I'm one of the commiters to blame :-) I made a quick search and see two ways to eliminate them : - edit/indent/remove trailing whitespace (must select all before), to do before a save. - use plugin whitespace : better since automatic (requires jedit = 4.3) I use jedit 4.2 so will have to upgrade... Jean-Louis 2011/8/8 Mark Miesfeld miesf...@gmail.com On Mon, Aug 8, 2011 at 1:18 PM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: If a script would take automatically take care of stripping off whitespace, then no one is forced to configure his editor to do that automatically. AFAIK subversion/svn allows for defining hook scripts. It does allow hook scripts, but that is not much use here because it won't work well. Or is at least is advised against. Pre-commit hooks can only be used to prevent a transaction, they can not modify the transaction. A post-commit hook that removed the whitespace would then require a second commit. I've seen this advised against, although I guess that could come down to individual like or dislike. It would certainly leave the committer's file out of sync with the repository immediately after the commit. I personally would rather configure my editor than deal with that. grin Most cooperative projects I've looked at, require the programmer to conform to the style guidelines, if they have them, rather than changing code after it is committed. -- Mark Miesfeld -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Question ad segmentation fault: who could be mostlikely the culprit ?
Hi there, While stress-testing a part of the dbus language binding in an area (private DBUS server) there is a chance that I hit problems in libdbus.so itself in that area (as some comments indicate that multi-threading in the server may need more testing). Now from time to time I would get segmentation faults, but rarely traces. Now I got a backtrace, but am not really able to read/determine whether the culprit is likely to be libdbus.so (the dbus reference library implementation), my language binding or ooRexx or glibc. *** glibc detected *** /usr/bin/rexx: double free or corruption (fasttop): 0x00da8980 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x78a8f)[0x7f92a0eefa8f] /lib/x86_64-linux-gnu/libc.so.6(+0x7b1bb)[0x7f92a0ef21bb] /lib/x86_64-linux-gnu/libc.so.6(realloc+0xf9)[0x7f92a0ef3b19] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x28321)[0x7f929e7f1321] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x28a98)[0x7f929e7f1a98] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x14217)[0x7f929e7dd217] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x14c18)[0x7f929e7ddc18] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x14f46)[0x7f929e7ddf46] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x1295f)[0x7f929e7db95f] /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x12e35)[0x7f929e7dbe35] /lib/x86_64-linux-gnu/libdbus-1.so.3(dbus_message_new_method_call+0xfc)[0x7f929e7e0a4c] /usr/lib/libdbusoorexx.so(DbusBusCallMessage_impl+0x5d0)[0x7f929ea1ed49] /usr/lib/libdbusoorexx.so(DbusBusCallMessage+0x93)[0x7f929ea1e75f] /usr/lib/ooRexx/librexx.so.4(_ZN20RexxNativeActivation3runEP10RexxMethodP16RexxNativeMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0xce)[0x7f92a20d91ae] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject+0x71)[0x7f92a2098361] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject22processProtectedMethodEP10RexxStringP10RexxMethodPPS_mR15ProtectedObject+0x7d)[0x7f92a20a3f4d] /usr/lib/ooRexx/librexx.so.4(_ZN21RexxExpressionMessage8evaluateEP14RexxActivationP19RexxExpressionStack+0x256)[0x7f92a20fed36] /usr/lib/ooRexx/librexx.so.4(_ZN21RexxInstructionReturn7executeEP14RexxActivationP19RexxExpressionStack+0x44)[0x7f92a210cd44] /usr/lib/ooRexx/librexx.so.4(_ZN14RexxActivation3runEP10RexxObjectP10RexxStringPS1_mP15RexxInstructionR15ProtectedObject+0x11c)[0x7f92a20d1c9c] /usr/lib/ooRexx/librexx.so.4(_ZN8RexxCode3runEP12RexxActivityP10RexxMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0x73)[0x7f92a20d5363] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject+0x71)[0x7f92a2098361] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject11messageSendEP10RexxStringPPS_mR15ProtectedObject+0xd3)[0x7f92a20a47d3] /usr/lib/ooRexx/librexx.so.4(_ZN21RexxExpressionMessage8evaluateEP14RexxActivationP19RexxExpressionStack+0x256)[0x7f92a20fed36] /usr/lib/ooRexx/librexx.so.4(_ZN25RexxInstructionAssignment7executeEP14RexxActivationP19RexxExpressionStack+0xf8)[0x7f92a2102298] /usr/lib/ooRexx/librexx.so.4(_ZN14RexxActivation3runEP10RexxObjectP10RexxStringPS1_mP15RexxInstructionR15ProtectedObject+0x11c)[0x7f92a20d1c9c] /usr/lib/ooRexx/librexx.so.4(_ZN8RexxCode3runEP12RexxActivityP10RexxMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0x73)[0x7f92a20d5363] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject+0x71)[0x7f92a2098361] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject11messageSendEP10RexxStringPPS_mR15ProtectedObject+0xd3)[0x7f92a20a47d3] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject11sendMessageEP10RexxStringPPS_m+0x38)[0x7f92a20a5088] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObjectnwEmP9RexxClassPPS_m+0x6f)[0x7f92a20a513f] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject7newRexxEPPS_m+0x17)[0x7f92a20a51b7] /usr/lib/ooRexx/librexx.so.4(_ZN7CPPCode3runEP12RexxActivityP10RexxMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0x184)[0x7f92a20cc614] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject+0x71)[0x7f92a2098361] /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject11messageSendEP10RexxStringPPS_mR15ProtectedObject+0xd3)[0x7f92a20a47d3] /usr/lib/ooRexx/librexx.so.4(_ZN21RexxExpressionMessage8evaluateEP14RexxActivationP19RexxExpressionStack+0x256)[0x7f92a20fed36] /usr/lib/ooRexx/librexx.so.4(_ZN21RexxInstructionReturn7executeEP14RexxActivationP19RexxExpressionStack+0x44)[0x7f92a210cd44] /usr/lib/ooRexx/librexx.so.4(_ZN14RexxActivation3runEP10RexxObjectP10RexxStringPS1_mP15RexxInstructionR15ProtectedObject+0x11c)[0x7f92a20d1c9c] /usr/lib/ooRexx/librexx.so.4(_ZN8RexxCode3runEP12RexxActivityP10RexxMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0x73)[0x7f92a20d5363]