Re: [Somelib] Trying to grasp what the processes are for creating a SOME object

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

To start with, I'm going to have a little trouble with fixing CVS right
now, sorry.  I destroyed my Linux install, well, just the gui, I guess I
could do some stuff from the command line.  I'll get it done as soon as
possible.  I have spent countless hours trying to get Windows to be able to
use ssh to get into the CVS server, to no avail yet.

The first thing to remember when using SOMELib is that your plugin classes
must be created dynamically.  Since there is nothing I hate more than
forgetting to delete objects created "outside my power", I created
SOMEObject (formerly SOMEPluginObject) to be a reference counted smart
pointer.  What this means is that you treat your SOMEObject<foo_interface>
exactly as a foo_interface*.

The idea then is that SOMELib factory will provide you with the
SOMEClassInfo's you need.  I guess your point of having to get the
ClassInfo then create the Object is a good one.  I'm not sure if I had a
good reason for that besides thats the way I developed it to make sure all
the pieces were working.  I suppose my best justification is that you may
want to construct multiple objects, in which case you would want to get the
ClassInfo once and make multiple Objects with it.  I will add a function to
retrieve a pre-construct()-ed SOMEObject to SOMELibFactory.  The problem
with that is having another template member function because of constructor
parameters, that's a real pain.  But. like you said, complexity should be
on the shoulders of the implementor, not the user.

I do think that requiring the creation of the ClassInfo in the dynlib is a
useful requirement.  I need to write a function so you don't have to create
the vector of ClassInfo's yourself though.  Also, I just learned the trick
with macros to "dereference" the symbol within another string, so I'm going
to change the macros so all you say is
DEFAULT_CONSTRUCT_FUNC(BasicPluginObj) and it will create the function
create_default_BasicPluginObj().  I'll figure out an easy way to put those
functions into the LibInfo in the init function.

Did that clear anything up?  I'll try again if not.

tom

John Palmieri wrote:

> I was going over the code and I am getting a bit confused on how it
> creates an object.  One sticking point is the Info class.  What exactly
> is the code doing?  It looks a bit non-standard and I want to keep the
> implementation of SOMEObjects as easy as implementing standard C++
> objects.  If this means putting the burden of complexety on the SOMELib
> side then so be it.  Better to have the library be complicated once
> instead of the objects being complicated every time you want to create a
> new one.  Perhaps I am just tired and I am just not seeing the
> simplicity in design here (I did have two tests today).  What I want is
> to be able to create an object foo such as:
>
> class foo():public foo_interface{
>     foo();
>     ...
>     virtual std:string doFoo();
>     ...
>     etc.
> }
>
> And then be able to load and use it:
>
> foo_interfaces foo_obj = somehow_get_a_ref_to_foo();
> std:cout<<foo_obj->doFoo()<<std:endl;
>
> While having an info class for dynamic intefaces is great it unneedingly
> complicates the static plugin interfaces which don't change.  Is there a
> way to create objects without the info classes and save the info class
> for when we implement dynamic interfaces?  Or am I just missing the
> whole point of the info class?
>
> -Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

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