Menu
▾
▴
Re: [Corelinux-develop] Changes to MetaType
|
From: Frank V. C. <fr...@co...> - 2000-10-30 05:49:15
|
First off: CVS now contains the implementation of MetaType::dispatch.
The example code shows off how this is used by declaring a new aggregate
type (UserType). The macros which enable this are at the bottom of
UserType.cpp.
John,
Ok, couple of things for you so we are on the same page. In regards to
class WhatEver and class MetaType :
Classes elect to have a MetaType (helper macros)
A MetaType is a glorified RTTI class, and a light weight broker with the
ability to invoke methods through indirection.
A MetaType contains information about hierarchical structure and
location, any attributes declared to the MetaType, and about functions
available to be called.
MetaTypes are statically constructed and float around except for their
"parents" linkage (not a hard link, the parents are a array of MetaType
pointers constructed at compile time).
This is the first step we needed to complete in order to enable some
level of reasoning within the CoreLinux++ provided frameworks. For
example, the LibraryType class derivations (which can include Function,
Graphic, etc.) will be "known" to respond to queries about what types of
libraries it can handle, so (pseudo code):
// Asssume we're iterating through a collection of library type handlers
//
LoaderPtr n::getLoaderForLibrary( char *aName )
{
while( itr != end )
{
bool itDoes;
(*itr).second->dispatch
(
"HandlesThisLibrary",
(void **)aName,
(void *)&itDoes
);
if( itDoes == true )
{
}
}
}
The next step we were going to take was to define an Ontology (
organization of types with a few twists to support semantic reasoning
). Clearly, the static MetaTypes will need to "register" themselves into
the Ontology.
Once an Ontology is done it will be easy enough to construct a MetaType
programatically, through dynamic magic, or by hand (as I am doing now
with all these macros (yechh)).
Having said that I think we are looking at the problem with the same
general ideas to solving it.
Perhaps a chat meeting soon can shine an even brighter light on the two
directions and thoughts?
"John A. Palmieri" wrote:
>
> Sounds good. I think we might be able to go this way in SOMELib. I
> agree it is much better than the method call. The only problem comes
> with name clashes and the ability to link a file statically if a
> programmer so chooses. One way to avoid clashes ( especially with
> overloaded functions) is to create method signatures. For example a
> method doSomething from object A with arguments of int and string should
> be given the signature A_doSomething_int_string (or similar
> signatures). I think we should standardize on the format of the
> signature and macros used to create lookups though I think the lookup
> tables should be separate from the object itself. For example
>
> UnkownObject anA(get reference to A's MetaType depending on library
> (CoreLinux or SOMELib or other)); //A does not have to inherit from any
> class because all information is loaded from the metatype
> //UnkownObject builds reference table based on MetaType information
> (SOME::ClassCatalog in SOMELib)
>
> anA.invokeMethod("doSomething", BIND_PARAMS(x, y)); //I like this name
> better than dispatch. We could use the same functionality as printf for
> multiple parameters instead of using a macro to bind them but this could
> be library dependent.
>
> The reason for leaving the implementations of the lookup table outside
> the actual object and inside the specific library is so that we don't
> have to compromise over implementation. The only thing that is the same
> is the C function names, the macro's and their implementations for
> creating the C functions, and the format for the metadata which could be
> as easy as
> {
> "meta_classname"="A",
> "meta_methodc"="1", //number of methods in this class
> "meta_methodname[0]"="doSomething", //name of the first method
> "meta_methodinvocator[0]"="A_doSomething_int", //signature of the c
> function call
> "meta_argc[0]"="1", //number of args this method takes
> "meta_argt[0][0]"="int", //the arg type for argument 1 of method 1
> "meta_ret"="int" //the return type
> }
>
> With this a person could even turn a C library into a scriptable object
> that can be used by SOMELib and CoreLinux++ by just supplying metatype
> information for that library. The way we supply MetaType information
> and library entry points for each project is different but at the source
> level at least implementation of the classes themselves can be the same
> and we can possibly move towards binary compatibility after that (with
> bindings for each metatype format and library entry points). I am on my
> way to creating a preparser for automating the MetaType stuff straight
> from the header files. I should be able to easily expand it to support
> the scriptable interfaces and both SOMELib and CoreLinux++'s formats
> (generated from IDL files). Of course the scriptable interfaces will be
> part of SOMELib 2.0 as we expect 1.0 to be packaged soon.
>
> Tell me what you think.
In regards to the last (compiler), Christophe (who may be on the way to
France as we speak) had some ideas along this line. But, we are probably
not going to be ready until CoreLinux++ has a persistent framework in
place. It would not be reasonable to expect that the user/devloper would
need to recompile the metainformation and then load it all the time.
I have been looking at RDFS (Resource Descriptor Framework Schema) as a
way to capture and import (through a XML parser) ontologies.
>
> -Quinticent
>
> "Frank V. Castellucci" wrote:
> >
> > Recent check-in includes the ability to declare a function dispatch
> > table, each member of the table containing a text descriptor and
> > function address that can be used to direct the appropriate object
> > method call.
> >
> > For example (lots of stuff omitted) :
> >
> > // in A.hpp
> >
> > class A : public virtual FrameworkEntity
> > {
> > DECLARE_METATYPEMEMBERS( A );
> > public:
> > int doSomething( int v );
> > };
> >
> > // in A.cpp
> >
> > // Either use macros or create by hand, to define the function
> > // If using the macro, then just provide the body
> > // **note the names
> >
> > DISPATCH_FUNCTION( A, doSomething )
> > *((int *)ret) = myPointer->doSomething( (int) args[0] );
> > CLOSE_DISPATCH_FUNCTION;
> >
> > // Which expands to
> >
> > static extern "C" void AdoSomething
> > (
> > FrameworkEntityPtr aClass,
> > void **args,
> > void *ret
> > )
> > {
> > A *myPointer = A::castdown( aClass );
> > *((int *)ret) = myPointer->doSomething( (int) args[0] );
> > }
> >
> > // Then create a dispatch descriptor
> >
> > DEFINE_DISPATCH_DESCRIPTOR( A, doSomething, doSomething );
> >
> > // where first arg is class
> > // second arg is stringified for lookup
> > // third arg is the method
> > //
> >
> > // Create the table to collect all descriptors
> >
> > OPEN_DISPATCH_TABLE( A )
> > DEFINE_DISPATCH_ENTRY( A, doSomething )
> > CLOSE_DISPATCH_TABLE;
> >
> > DEFINE_METATYPE( A, someid, someversion );
> >
> > // In user application, the ability will be used to call the method with
> > // the context of the instance (anA)
> >
> > int main( void )
> > {
> > A anA;
> > int x(5);
> > int y(0);
> >
> > anA.getType()->dispatch(&anA,"doSomething",(void **)&x,(void *)&y);
> > }
> >
> > The MetaType method (dispatch) should be in sometime tonight, all the
> > macros are in.
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> > http://PythPat.sourceforge.net
> > Pythons Pattern Package
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
|
