Re: [Corelinux-develop] Missing mail retry

[John P. (Quinticent) <jo...@ma...>]

I'm not sure if this is refrence to the Dynamic Interface stuff you wanted
us (SOMELib) to work with you on.  DataMarshling?  Are you creating out of
process C++ classes? SOMELib is mainly for inprocess object loading and if
you wish to go the out of process route I would like to suggest creating
orbit bindings for C++ since Linux seems to moving twords CORBA for
component systems.

Seeking of lost e-mails.  I had a long e-mail describinmg why Tom was
"scared" of using your Dynamic Interface design.  Of cource when I was about
to hit send netscape froze on me :-) Well to make it short, we believe that
C++'s RTTI and template functionality is enough to facilitate Scriptable
Interfaces without having to wrap simple datatypes.  SOMELib's goal is
simplicity and working with the knowlege that C++ programmers already have
without throwing them anything too new.  If you look at SOMELib right now a
developer can develop C++ objects normaly (with the restriction of only
allowing up to 2 parameter constructors) and then supply some information
via the SOMELibInfo and SOMEClassInfo classes about these object and he/she
is home free.  In fact the Descriptors will later be automated by a
preprocessor.  In the same spirit of simplicity scriptable interface will be
automate by simple providing a (perhaps IDL) interface file and running it
through a preprocessor before compile.  The interface file is needed because
sometimes you don't want scripts being able to access all public
functionality. The preprocessor will simply add a method for the entry point
of scripts to call methods and and descriptors to the SOMEClassInfo class on
what methods are available.  Builder programs can use these descriptors to
create object inspectors. Getter/setter patterns will be enforced for
properties(read only/read write/etc.) Along with anything else you would
expect to see in an object system.  No bumps or curveballs,  all streight up
standard C++ and the stuff that is not will eventualy be placed in the
preprocessor.  The only real learning curve is the intial loading of an
object but once it is loaded it can be used like any C++ object (of course
not with the Scripting Interface).  The Scripting interface would be more
like
vector<void *>args;
void *return_value;
ScriptObj->callMethod("setProperty", args, return_value);

Of course the object itself is defined like any other C++ object with an
extra Interface file.  The preprocessor will take care of adding the
callMethod method (we will have to mess with the name a bit so that it
doesn't clash with a developers method).  In that method is would have
something like
if(method=="setProperty_2args")//signiture
    this-> setProperty(dynamic_cast<string>*args[0],
                                  dynamic_cast<string>*args[1]);

Of course I have to expand on this idea a bit but let me know what you
think.
Return types are going to be the biggest headache.  It is up to the user to
enforce type constraints on their objects not SOMELib.  We need it to be
flexable.

-Quinticent

"Frank V. Castellucci" wrote:

> Mailing list are less than reliable these days.
>
> I have made a number of changes and additions to clfw.
>
> The example should pretty much show them off, as well as the headers for
> the new types.
>
> The wrappers are very vacuous as far as behavior, waiting for response
> from Christophe on the analysis of templates and meta information.
>
> Again, the MetaType::get and MetaType::set methods should make it clear
> that I am leaning towards a MOP (MetaObject Protocol) way of marshaling
> data between objects. Not necessarily for general usage, there is
> nothing to stop someone from adding methods galore outside of the
> knowledge of it's class descriptor, but to enable powerful extensions
> for the frameworks.
>
> --
> 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