Re: [Corelinux-develop] Missing mail retry

[Frank V. C. <fr...@co...>]

John,

I have copied you direct on this as the mailing list is taking up to two
(2) days to process messages. Perhaps we should all give up our projects
and fix THAT for SourceForge :)

"John Palmieri (Quinticent)" wrote:
> 
> 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.

The foundational wrapping is for our frameworks to reason with types.
One example will be when we need to load either functions or classes
from external libraries, another will be when we add a persistence
framework so that the persist engine does not require encoding schema
information into class declaration/definitions.

At some point you will have your library doing what you want, at some
point our framework will be were we want, here is where I had thought we
(CoreLinux++) could create an adapter or bridge for mapping between our
library and your interface for the purpose of function/class loading.
Time will tell.

My post of asking Tom what "scared" him about the framework design
something I thought he saw in the framework. While we are all concerned
with providing libraries that are "useable", I have had no compunction
about adding something complex to enhance the solution space options.
This may be my background of big systems work, where lots of things are
thought about. The biggest difference between SOMELib and CoreLinux++ is
that your library addresses a specific need (and will do it well it
appears), while CoreLinux++ is after a broad range of uses.

> 
> 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);

As this suggests, the simple turns to the complex and maintenance
required task on the developer. Adding preprocessors, script compilers,
etc., is a step I applaud and recognize that we (CoreLinux++) may
venture into to, but I don't consider this simple and non-intrusive.
This is not meant as a flame, but just my opinion on what defines
complex and what doesn't.


> 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]);

We have just added the foundation for doing something like this, but
limited at the moment to get/set operations on a per attribute level
(the templates are in the example code, not the type modules) :


// Getter

template < class T > T getValue( char *name, FrameworkEntityPtr aFE )
{
   T  *pval( NULLPTR );

   pval = (T *) (aFE->getType())->get(name,aFE);

   return *pval;
}

// Setter

template < class T > void setValue
   ( 
      char *name, 
      T value, 
      FrameworkEntityPtr aFE 
   )
{
   (aFE->getType())->set(name,(VoidPtr)&value,aFE);
}

//
// Main entry point
//

int main( void )
{

  //
  // Practice gracefull exception management
  //

   try
   {

      //
      // Now we sweeten the pot with showing the factory methods, 
      // introspection, getters, setters, and destructors
      //

      // signed Integer

      IntegerPtr   aInteger = Integer::create();

      setValue<Int>("Value",8,aInteger);

      cout  << "Value of aInteger = " << 
         getValue<Int>("Value",aInteger) << endl;

      Integer::destroy( aInteger );
    }
    catch( ... )
    {
      //
    }

    return 0;
}

Of course, aInteger could have been instantiated using aInteger = new
Integer (we override new and delete in each class and provide a factory
allocator).
 
> 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.

I think this is similar to the design we have for the
ExecutionObjectDefinition (sans the if statements)
http://corelinux.sourceforge.net/doc/design/4865.php, which captures the
argument types and return type. A kind of blueprint, if you will, for
the actual call. 

> 
> -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
> 
> _______________________________________________
> 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