It is a little unclear from the functional requirements as to the intent of the MetaClass ontology.
Is it a static compilation time class DAG or is it a dynamic type creation system that allows me to prototype new types and semantics? The dynamic approach could allow for the creation of new types and allow coercion of parent types into the newly created type. This coupled with some sort of dynamic dispatch mechanism could even allow for method extension.
Just a thought
Tom
First off, the statements made in regards to ontology are to elucidate some terminology that may not be familiar to the focus audience (C++ developers). After all, many a C++'er idea of type information is what you get out of RTTI. I am very familiar with conceptual modeling, and run-time instantiation for reasoning and reification, I just couldn't
assume the rest of the world was.
Having done that, and apparently hooking a fish right off the bat <grin>, the next step was to realize, through feedback, whether or not this would be a useful addition, or would it hopelessly complicate the implementation and use of the class libraries.
The subject attained rights of passage because of my struggle of trying to design the FunctionLibrary Loader without meta-class and type ontologies. I played with alternative ideas to find some elegant and correct way to express arguments and return types that don't just flop
into the domain (application developers) solution space. I can find no better way. Obviously this would be available to all extensions thereby normalizing how these type situations (no pun intended) could be dealt with cleanly, and without rewriting the wheel.
Once I started walking down the meta-class path, Christophe and I discussed the potential for a dynamic IDL type declarative parser to create types "on the fly" if you will. But discussing this to some level I fell that there is a thin line between what we want to achieve and full out object brokering. I don't not want to go for the latter!
From the short term, again, I am interested in being able to express types, not prototypes, with some level of attribute expressiveness.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To enable marshalling between components and a object instance, the macros will be expanded to both insure the declarations of the data members and accessor/mutator are provided.
This will also require that the MetaType be able to store information neccessary to utilize these methods. In this way, a client can delegate the getting/setting activity of data via the MetaType instance and the object instance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An implementation to support declaring and defining accessors/mutators has been checked into CVS. There may be some cleanups and/or extensions yet so....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The need for the ontology management is coming up quicker than expected. I will forstall the implementtion for a "wee" bit longer until the types start to settle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Changes that will appear in 0.2.2 include the class and the meta ontology following the same lineage. It seems reasonable and right that if asking a ShortInteger if it is a Integer (which it would reply yes), that access to the object as an Integer would need to be enabled.
For situations like this, new macros have been added which allow you to define accessor/mutators which delegate to the underlying storage member.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Either here or on the mailing list.
The website has the functional requirement specification and it should be considered a live document.
> Thomas Maguire wrote:
It is a little unclear from the functional requirements as to the intent of the MetaClass ontology.
Is it a static compilation time class DAG or is it a dynamic type creation system that allows me to prototype new types and semantics? The dynamic approach could allow for the creation of new types and allow coercion of parent types into the newly created type. This coupled with some sort of dynamic dispatch mechanism could even allow for method extension.
Just a thought
Tom
First off, the statements made in regards to ontology are to elucidate some terminology that may not be familiar to the focus audience (C++ developers). After all, many a C++'er idea of type information is what you get out of RTTI. I am very familiar with conceptual modeling, and run-time instantiation for reasoning and reification, I just couldn't
assume the rest of the world was.
Having done that, and apparently hooking a fish right off the bat <grin>, the next step was to realize, through feedback, whether or not this would be a useful addition, or would it hopelessly complicate the implementation and use of the class libraries.
The subject attained rights of passage because of my struggle of trying to design the FunctionLibrary Loader without meta-class and type ontologies. I played with alternative ideas to find some elegant and correct way to express arguments and return types that don't just flop
into the domain (application developers) solution space. I can find no better way. Obviously this would be available to all extensions thereby normalizing how these type situations (no pun intended) could be dealt with cleanly, and without rewriting the wheel.
Once I started walking down the meta-class path, Christophe and I discussed the potential for a dynamic IDL type declarative parser to create types "on the fly" if you will. But discussing this to some level I fell that there is a thin line between what we want to achieve and full out object brokering. I don't not want to go for the latter!
From the short term, again, I am interested in being able to express types, not prototypes, with some level of attribute expressiveness.
Added the need to predefine (in libclfw++) entities and meta-types:
Number
Real
Integer
ShortInteger
LongInteger
Unisgned Integer
String
Character
MetaTypeNumber
MetaTypeReal
MetaTypeInteger
MetaTypeShortInteger
MetaTypeLongInteger
MetaTypeUnisgnedInteger
MetaTypeString
MetaTypeCharacter
The initial declaration and definition macros are in CVS, and there is a small test driver as well.
We will release 0.2.0 of libclfw with this work soon.
libclfw++ 0.2.0 was released Oct 04 2000
To enable marshalling between components and a object instance, the macros will be expanded to both insure the declarations of the data members and accessor/mutator are provided.
This will also require that the MetaType be able to store information neccessary to utilize these methods. In this way, a client can delegate the getting/setting activity of data via the MetaType instance and the object instance.
An implementation to support declaring and defining accessors/mutators has been checked into CVS. There may be some cleanups and/or extensions yet so....
Even though we have included a way to describe a Type attribute, we will still be working to providing MetaType attribute capability.
In regards to Integer and Real the question has come up whether Integer is a Real number, or a constrained Real number.
Anyone?
The need for the ontology management is coming up quicker than expected. I will forstall the implementtion for a "wee" bit longer until the types start to settle.
Support for MetaSpace (the management of ontologies) and Ontology has been checked in, although not complete.
This was done to get something out to interested parties early, work will continue.
Added RealNumber type. It's metaclass MetaTypeRealNumber is subsumed by MetaTypeNumber.
Integer type derives from Number, but MetaTypeInteger is subsumed by MetaTypeRealNumber
Includes the RealNumber and Integer types, along with associated MetaTypes. Minor fix to MetaType::isTypeOf
Changes that will appear in 0.2.2 include the class and the meta ontology following the same lineage. It seems reasonable and right that if asking a ShortInteger if it is a Integer (which it would reply yes), that access to the object as an Integer would need to be enabled.
For situations like this, new macros have been added which allow you to define accessor/mutators which delegate to the underlying storage member.
Added recently with some changes to MetaType to support get and set without iterating through the descriptors in the application code
Subsumed by UnsignedInteger
Prototype type is in. A prototype captures the definition of a class, as opposed to simple types.
Oops! Collision with prototype from libcorelinux++, changed to Aggregate.
MetaType.hpp contains macros for declaring and defining a function dispatch table. This allows the indirection of methods in a "classless" manner.