Re: [Corelinux-develop] Changes to MetaType

[John A. P. <qui...@ao...>]

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.

-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