corelinux-develop

[Corelinux-develop] Missing mail retry

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

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

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

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

Re: [Corelinux-develop] Missing mail retry

[Thomas M. <tma...@ze...>]

"Frank V. Castellucci" wrote:

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

My biggest problem with projects like CoreLinux++ is when they become all or
nothing.  While it is a pain to rely on 12 different projects, being able to pick
your functionality from the best place is great.  If the library loader relies on
the persistence framework which relies on the property accessing methods which
rely on the enhanced RTTI methodology, that is when I say nevermind.  If this is
not true in CoreLinux++, hooray.  Just my opinion.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Corelinux-develop] Missing mail retry

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

Thomas Matelich wrote:

> "Frank V. Castellucci" wrote:
>
> > 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.
>
> My biggest problem with projects like CoreLinux++ is when they become all or
> nothing.  While it is a pain to rely on 12 different projects, being able to pick
> your functionality from the best place is great.  If the library loader relies on
> the persistence framework which relies on the property accessing methods which
> rely on the enhanced RTTI methodology, that is when I say nevermind.  If this is
> not true in CoreLinux++, hooray.  Just my opinion.
>

Well said and I agree, and you can say hooray!

More clarification:

CoreLinux++ is not A framework, but many. It is not our intent to tightly couple each
framework to each other, our disciplines will ensure that. In the event it is
natural, for say the Persistence framework to use some kind of library loading
capability, then we of course we use the abstraction of the Library Load framework.
But it would be up to the solution space to instantiate the appropriate derivation.

By the same token, our frameworks are to be "plug-in-able", if the user selects a
persistence framework implementation that doesn't require other frameworks, that is
fine as well.

>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

Re: [Corelinux-develop] Missing mail retry

[Thomas M. <tma...@ze...>]

"Frank V. Castellucci" wrote:

> CoreLinux++ is not A framework, but many. It is not our intent to tightly couple each
> framework to each other, our disciplines will ensure that. In the event it is
> natural, for say the Persistence framework to use some kind of library loading
> capability, then we of course we use the abstraction of the Library Load framework.
> But it would be up to the solution space to instantiate the appropriate derivation.
>
> By the same token, our frameworks are to be "plug-in-able", if the user selects a
> persistence framework implementation that doesn't require other frameworks, that is
> fine as well.

Great, now I have to quit complaining :)  So my question then is why Core*Linux*?  Is
this merely a dependency/complexity management issue?  That is a very good issue.  I
guess I could start working on CoreWindows++ and CoreHPUX++, or maybe CoreLinux++*3, if
I wanted to use it.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Corelinux-develop] Missing mail retry

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

Thomas Matelich wrote:

> "Frank V. Castellucci" wrote:
>
> > CoreLinux++ is not A framework, but many. It is not our intent to tightly couple each
> > framework to each other, our disciplines will ensure that. In the event it is
> > natural, for say the Persistence framework to use some kind of library loading
> > capability, then we of course we use the abstraction of the Library Load framework.
> > But it would be up to the solution space to instantiate the appropriate derivation.
> >
> > By the same token, our frameworks are to be "plug-in-able", if the user selects a
> > persistence framework implementation that doesn't require other frameworks, that is
> > fine as well.
>
> Great, now I have to quit complaining :)  So my question then is why Core*Linux*?  Is
> this merely a dependency/complexity management issue?  That is a very good issue.  I
> guess I could start working on CoreWindows++ and CoreHPUX++, or maybe CoreLinux++*3, if
> I wanted to use it.

Because the multi-thread execution profile uses "clone" versus LinuxThreads, and the idea
of the library was specifically targeted to a Linux environment.

>
>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop