somelib-devel — Public mailing list for design discussion and bug reports

Re: [Somelib] Another checkin

[John P. <jo...@ma...>]

Sounds good.  I'll look at it tomorow.  I just made some major
breakthroughs in my other project and I will be integrating SOMELib soon.

One thought on the Info classes.  Can you show me how these work.  I don't
quite follow the code.  Say I have a class such as:

class Sprite {
      public:
             Sprite();
             Sprite( string fileName );
             ~Sprite();

             void render( int x, int y );
             bool load( string fileName );

       private:
              string _fileName;
              char *rawGraphics;
};

How would I convert this into a SOMEObj?

and say I normaly use it like this:

main(){
.
.
.
Sprite sp = new Sprite("tux.png");
sp->render(100,100);
.
.
.
}

How would I convert this for use with SOMELib?

You see I want to keep the syntax generaly the same with a few extras but
not so much that it becomes as complicated as COM or Corba.  If that ever
happend then we are beyond the scope of our project.  If extras like the
Info class are absolutly needed then perhaps we can rig a pre-parser to
handle all the gorry details of setting up the vectors.  Well just a
thought.

-John Palmieri

Thomas Matelich wrote:

> I made some of the changes we talked about.  I have not added the
> ability to get a SOMEObj directly from the factory yet (kind of dragging
> my heels on that one because I just don't like it).  John, if you could
> fix up the configure stuff when you get a chance.  I noticed that I was
> linking BasicTestLib to TestApp which is silly.  But because I did that,
> I had to make libSOME into an SO, because TestApp wasn't pulling in all
> the symbols necessary.
>
> How would we go about making configure automatically set up our choice
> of dll access?
>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

[Somelib] Another checkin

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

I made some of the changes we talked about.  I have not added the
ability to get a SOMEObj directly from the factory yet (kind of dragging
my heels on that one because I just don't like it).  John, if you could
fix up the configure stuff when you get a chance.  I noticed that I was
linking BasicTestLib to TestApp which is silly.  But because I did that,
I had to make libSOME into an SO, because TestApp wasn't pulling in all
the symbols necessary.

How would we go about making configure automatically set up our choice
of dll access?

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

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

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

[John P. <jo...@ma...>]

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] Compile errors

[John P. <jo...@ma...>]

Since the SOMEUnkownInterface.h has been taken out SOMELib build has
broken.  Please take out all refrences to SOMEUnkownInterface and commit
the changes.

-Quinticent

Re: [Somelib] SOMEUnknown*

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

Remove them and rename :-)

-Quinticent

Thomas Matelich wrote:

> I am considering removing these classes as they don't appear to provide
> any real benefit to the user.  Scratch that, they don't provide any
> benefit.  So, any objections to their removal?  Also, should
> SOMEPluginObj be renamed to SOMEObj?
>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

Re: [Somelib] Linux makefiles now in CVS

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

Thomas Matelich wrote:

>
> Have you had the opportunity to use it much.

I just started testing it.  I will be integrating it as my object model in
Snaglepuss as soon as I am finished rewritting it(Snaglepuss) to use the STL.

> Feature requests would be
> much appreciated.  I'm working on it when I can, but I'm low on ideas as to
> what else to put in.
>

Well then let's crank this puppy out as 0.9 beta.  Make some anouncements on
sourceforge and create some tarballs. After we get this to 1.0 our goal for 2.0
is to work with the CoreLinux++ team on dynamic interfaces.  The goal there is
to allow developers to write to 1 API for dynamic interfaces and run it using
CoreLinux++ or SOMELib.  For right now comment the hell out of it.  75% of a
project like this is documentation.  If people don't know how to use it they
won't.

>
> Do you think we should have kdoc/doxygen/whatever type comments in the code
> to generate our API?
>

Sounds good as long as the project is not dependent on kdoc/doxygen/etc...

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

-Quinticent

[Somelib] SOMEUnknown*

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

I am considering removing these classes as they don't appear to provide
any real benefit to the user.  Scratch that, they don't provide any
benefit.  So, any objections to their removal?  Also, should
SOMEPluginObj be renamed to SOMEObj?

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

Re: [Somelib] Linux makefiles now in CVS

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

John Palmieri wrote:

> SOMELib complies under Linux once again.  Well at least my Debian Linux
> (potato).  Grab the sources while they are hot.  The Makefiles are a tad
> messy and configure doesn't do much besides find out the compiler to
> use.  WHen compiling for the first time it spits out a bunch of file not
> found errors.  Don't worry as these are just the dependancy checking
> stuff and since I am not using recursive makes it gets a bit messed up.
> It should be fixed but my main goal was to just get it to compile.  Ne1
> out there want to maintian the linux build stuff.

You had given me the address of someone who had expressed interest in that
before.  I wrote him but received no response.  I seem to have lost those
emails, though.

> Tmake is great but not part of the GNU tool chain.  I would like to
> stick with gmake, and autoconf.  Automake creates unreadable makefiles
> so I stay away from it also.

I used tmake because of the Windows/*nix compatibility and simplicity.  I
have no problem with
maintaining autoconf and Windows project file separately.

>  I will write up guideline docs on how to create your own objects and
> compile them under linux in the near/distant future.  If people realy
> want this, let me know so I will kick my butt
> into gear othewise I have other more pressing things on my mind these
> days.  <SHAMELESS PLUG>One of which is my talk at LILUG the Long Island
> Linux User Group on developing for open source.  I still have to write
> it up so I don't know when I will give it but I am giving a big chunk of
> time descussing SOMELib and how it developed.  I'll let everyone know so
> you can check it out if you are in the NY area.</SHAMELESS PLUG>
>
> Well that is it.  Code is looking good and hopefully it will reach 1.0
> fairly soon.

Have you had the opportunity to use it much.  Feature requests would be
much appreciated.  I'm working on it when I can, but I'm low on ideas as to
what else to put in.

Do you think we should have kdoc/doxygen/whatever type comments in the code
to generate our API?

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

[Somelib] Linux makefiles now in CVS

[John P. <jo...@ma...>]

SOMELib complies under Linux once again.  Well at least my Debian Linux
(potato).  Grab the sources while they are hot.  The Makefiles are a tad
messy and configure doesn't do much besides find out the compiler to
use.  WHen compiling for the first time it spits out a bunch of file not
found errors.  Don't worry as these are just the dependancy checking
stuff and since I am not using recursive makes it gets a bit messed up.
It should be fixed but my main goal was to just get it to compile.  Ne1
out there want to maintian the linux build stuff.

Tmake is great but not part of the GNU tool chain.  I would like to
stick with gmake, and autoconf.  Automake creates unreadable makefiles
so I stay away from it also.  I will write up guideline docs on how to
create your own objects and compile them under linux in the near/distant
future.  If people realy want this, let me know so I will kick my butt
into gear othewise I have other more pressing things on my mind these
days.  <SHAMELESS PLUG>One of which is my talk at LILUG the Long Island
Linux User Group on developing for open source.  I still have to write
it up so I don't know when I will give it but I am giving a big chunk of
time descussing SOMELib and how it developed.  I'll let everyone know so
you can check it out if you are in the NY area.</SHAMELESS PLUG>

Well that is it.  Code is looking good and hopefully it will reach 1.0
fairly soon.

Quinticent

Re: [Somelib] Greetings

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

"John A. Palmieri" wrote:
> 
> Hi Frank,
> 
> I started SOMELib.  Right now I play a minor role in the development
> though I keep an eye on design and such and put in my $.02 now and
> again.  Thomas does the bulk of the development right now.  When you
> talk about having knowledge that goes "way back to SOM"  are you talking
> about my original releases of SOMlib(simple object model) or IBM's
> SOM(system object model)?  

System Object Model

> I had changed the name to SOMELib to avoid
> confusion.  Ours is a simple inprocess object model for extending
> dynamic object loading on Linux and now Windows systems.  The new
> codebase is completely rewritten and is currently in its alpha stage.
> It in fact does not even have Makefiles for Linux yet.
> 
> SOMELib is meant to be a simple library with not much higher level
> functionality and almost no dependencies other than standard
> components.  In other words a person can drop in SOMELib and use it just
> as if they were using c's dynamic loading facilities (at bit more
> complex than that but you get the idea).  Theoretically you should be
> able to create a CoreLinux++ loadable object that has the ability to
> load SOMELib objects very easily and with little overhead.
> 
> As for collaboration on a standard for metaclasses/metatype classes for
> reflection/introspection.  I think this would be great.  Having a
> standard for such a task would alleviate the pains of developers and
> would allow people to chose what implementation they wish to use.  For
> crossplatformability alacart SOMELib and for full linux standards with
> many backup classes CoreLinux++.  So it sounds like fun.  Is there a
> mailing list setup for this yet?
> 
> Our main concern with SOMELib is to not sacrifice simplicity and as long
> as this does not I am all for it.
> 
> -Quinticent
> 
> SOMELib
> http://sourceforge.net/projects/somelib/
> C++ object loading
> 
> The Snaglepuss Project
> http://sourceforge.net/projects/snaglepuss/
> Multimedia development engine

Yes, I can understand that, and as CoreLinux++ is not targeted to other
platforms, it makes sense.

Well, if anyone wants to throw in their $0.02 we have a
corelinux-develop mailing list. There is some information in the archive
concerning meta-types.

There is also the (in progress) MetaClass functional requirement:

http://corelinux.sourceforge.net/doc/requirements/req10658.php

and the Library Load abstraction design (although a Function Library
Load theoretical specialization is shown as well):

http://corelinux.sourceforge.net/doc/design/4865.php

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

> 
> "Frank V. Castellucci" wrote:
> >
> > I am the project admin for CoreLinux++. I have experience in declarative
> > object modeling, knowledge representation, meta-models, and way back to
> > SOM.
> >
> > Our objectives were to create a core library (90% complete) and then
> > develop common framework abstractions (libclfw++) which we have just
> > begun.
> >
> > For example, we have already put in the Library Load abstraction with
> > the intent to construct specialized derivations (such as Function
> > Library Load, Image Library Load, etc.). It was obvious that the
> > metaclass/metatype objects would be very useful in this and many other
> > framework plans for reflection, reasoning, and reification.
> >
> > So my reason for posting to this list is to see if there is any interest
> > in joining forces in CoreLinux++ with the intent to extend
> > metaclass/metatype/meta-attribute paradigm to further specialize the
> > libraries.
> >
> > This has immediate applications in our plans for Persistence, Class
> > Loading, Toolbox function reasoning, and type ontology management.
> >
> > Looking forward to your response.
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> > _______________________________________________
> > somelib-devel mailing list
> > som...@li...
> > http://lists.sourceforge.net/mailman/listinfo/somelib-devel
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

Re: [Somelib] Greetings

[John A. P. <jo...@ma...>]

Hi Frank,

I started SOMELib.  Right now I play a minor role in the development
though I keep an eye on design and such and put in my $.02 now and
again.  Thomas does the bulk of the development right now.  When you
talk about having knowledge that goes "way back to SOM"  are you talking
about my original releases of SOMlib(simple object model) or IBM's
SOM(system object model)?  I had changed the name to SOMELib to avoid
confusion.  Ours is a simple inprocess object model for extending
dynamic object loading on Linux and now Windows systems.  The new
codebase is completely rewritten and is currently in its alpha stage. 
It in fact does not even have Makefiles for Linux yet.

SOMELib is meant to be a simple library with not much higher level
functionality and almost no dependencies other than standard
components.  In other words a person can drop in SOMELib and use it just
as if they were using c's dynamic loading facilities (at bit more
complex than that but you get the idea).  Theoretically you should be
able to create a CoreLinux++ loadable object that has the ability to
load SOMELib objects very easily and with little overhead.  

As for collaboration on a standard for metaclasses/metatype classes for
reflection/introspection.  I think this would be great.  Having a
standard for such a task would alleviate the pains of developers and
would allow people to chose what implementation they wish to use.  For
crossplatformability alacart SOMELib and for full linux standards with
many backup classes CoreLinux++.  So it sounds like fun.  Is there a
mailing list setup for this yet?

Our main concern with SOMELib is to not sacrifice simplicity and as long
as this does not I am all for it.

-Quinticent

SOMELib
http://sourceforge.net/projects/somelib/
C++ object loading

The Snaglepuss Project
http://sourceforge.net/projects/snaglepuss/
Multimedia development engine 

"Frank V. Castellucci" wrote:
> 
> I am the project admin for CoreLinux++. I have experience in declarative
> object modeling, knowledge representation, meta-models, and way back to
> SOM.
> 
> Our objectives were to create a core library (90% complete) and then
> develop common framework abstractions (libclfw++) which we have just
> begun.
> 
> For example, we have already put in the Library Load abstraction with
> the intent to construct specialized derivations (such as Function
> Library Load, Image Library Load, etc.). It was obvious that the
> metaclass/metatype objects would be very useful in this and many other
> framework plans for reflection, reasoning, and reification.
> 
> So my reason for posting to this list is to see if there is any interest
> in joining forces in CoreLinux++ with the intent to extend
> metaclass/metatype/meta-attribute paradigm to further specialize the
> libraries.
> 
> This has immediate applications in our plans for Persistence, Class
> Loading, Toolbox function reasoning, and type ontology management.
> 
> Looking forward to your response.
> 
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

[Somelib] Greetings

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

I am the project admin for CoreLinux++. I have experience in declarative
object modeling, knowledge representation, meta-models, and way back to
SOM.

Our objectives were to create a core library (90% complete) and then
develop common framework abstractions (libclfw++) which we have just
begun.

For example, we have already put in the Library Load abstraction with
the intent to construct specialized derivations (such as Function
Library Load, Image Library Load, etc.). It was obvious that the
metaclass/metatype objects would be very useful in this and many other
framework plans for reflection, reasoning, and reification.

So my reason for posting to this list is to see if there is any interest
in joining forces in CoreLinux++ with the intent to extend
metaclass/metatype/meta-attribute paradigm to further specialize the
libraries.

This has immediate applications in our plans for Persistence, Class
Loading, Toolbox function reasoning, and type ontology management.

Looking forward to your response.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Somelib] CVS Updated

[John P. <jo...@ma...>]

The CVS tree now has the current SOMELib revisions.  I am starting to
make minor changes here and there so developers should update their
local trees as often as possible and commit changes as soon as possible
to avoid anoying conflicts.  The latest changes I have made was to add
standard GNU files to the tree (ie AUTHORS, ChangeLog, BUGS, etc.)
along with the copyright notices for the LGPL in each of the source
files.  Tom, you should maintain these files to make sure they have up
to date info on what is going on with the projects.  Also a basic
Makefile needs to be supplied for the linux stuff.  Just make one that
will show me the compile chain (what files need to compile first/how
should I link them, etc.) and I will work on creating the Linux build
system using autoconfig.  Also, I need you to document the boost stuff
for me.  Just a couple of lines of what they do so I am not totaly
clueless :-) Also place the authors and the website of the boost stuff
that you lifted, in the AUTHORS file under the contributors section.

-Quinticent

Re: [Somelib] PROPOSAL: Enforcing factory patterns in SOMELib

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

John Palmieri wrote:

> I have just been reading an awsome book (Dessign Patterns; Eric Gamma,
> Richard Helm, Ralf Johnson, John Vlissides : Addison-Wesley:1995).  It
> describes the use of Factories to abstract the initilization of
> objects.  Factories take a group of similar objects and encapsulates
> them with itself.  (In essence each SOMELib object is a factory with
> only one object and SOMELib itself is a factory of all other objects)

Funny you should mention that.  I just added a new project to the cvs
repository yesterday (module name is some0-5) and I have done something
similar to that.  I have not finalized the design (still a fair amount of
functionality to be implemented), but I would welcome inspection and
comments.  It has only been tested on MSVC, I'm working on getting Linux
working currently.  There is code that is unused in there, so I would just
look at the TestApp and see what functionality is exercised there.

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

[Somelib] PROPOSAL: Enforcing factory pattern usage in SOMELib

[John P. <jo...@ma...>]

I have just been reading an awsome book (Dessign Patterns; Eric Gamma,
Richard Helm, Ralf Johnson, John Vlissides : Addison-Wesley:1995).  It
describes the use of Factories to abstract the initilization of
objects.  Factories take a group of similar objects and encapsulates
them with itself.  (In essence each SOMELib object is a factory with
only one object and SOMELib itself is a factory of all other objects)
The advantages to this in a plugin system is to allow for the user of
the plugin to use the SOMELib factory to obtain a refrence to a specific

factory object and then use that factory's interface to produce an
object that the user needs without the user needing to know the specific

object they are implementing.  Here is an example:

Say I write a graphics viewing plugin.  Well I could write a seperate
SOMEObject for each graphics type or I could write a factory that
exports the method getGraphics( string filename); and group all my
graphics objects (jpg, png, tiff, 3ds, etc.) into that factory.  The
factory would then load the apropriate object and pass it to the user.

The benefits are twofold, first it helps plugin writers to write more
reusible and better orginized code and second patterns are so well
documented(the STL is just a collection of objects based on patterns)
that most C++ programmers will see them and say, "ahhh, now
I understand".  Therefor I propose that all documentation and examples
should be written using the Factory pattern to facilitate understanding
and encourage users of SOMELib to follow our example.  Also, once again
messing with the namespace, the SOMELib object should me renamed to
SOMELibFactory and the initilization method should be changed to
getFactory( string factoryname ) or obtainFactoryRef( string
factoryname ).

Please comment.

-John Palmieri(Quinticent)

[Somelib] PROPOSAL: Enforcing factory patterns in SOMELib

[John P. <jo...@ma...>]

I have just been reading an awsome book (Dessign Patterns; Eric Gamma,
Richard Helm, Ralf Johnson, John Vlissides : Addison-Wesley:1995).  It
describes the use of Factories to abstract the initilization of
objects.  Factories take a group of similar objects and encapsulates
them with itself.  (In essence each SOMELib object is a factory with
only one object and SOMELib itself is a factory of all other objects)
The advantages to this in a plugin system is to allow for the user of
the plugin to use the SOMELib factory to obtain a refrence to a specific
factory object and then use that factory's interface to produce an
object that the user needs without the user needing to know the specific
object they are implementing.  Here is an example:

Say I write a graphics viewing plugin.  Well I could write a seperate
SOMEObject for each graphics type or I could write a factory that
exports the method getGraphics( string filename); and group all my
graphics objects (jpg, png, tiff, 3ds, etc.) into that factory.  The
factory would then load the apropriate object and pass it to the user.

The benefits are twofold, first it helps plugin writers to write more
reusible and better orginized code and second patterns are so well
documented(the STL is just a collection of objects based on patterns)
that most C++ programmers will see them and say, "ahhh, now
I understand".  Therefor I propose that all documentation and examples
should be written using the Factory pattern to facilitate understanding
and encourage users of SOMELib to follow our example.  Also, once again
messing with the namespace, the SOMELib object should me renamed to
SOMELibFactory and the initilization method should be changed to
getFactory( string factoryname ) or obtainFactoryRef( string
factoryname ).

Please comment.

-John Palmieri(Quinticent)

[Somelib] So are you talking about dynamic interfaces?

[John P. <jpa...@et...>]

>Of course, I could put some sort of interface functionality into a base
class,
>something like a map of strings to strings.  Base::setParam("name", value)?
>The interface spec in SOMEClassInfo would have the names, descriptions, and
> types.  We'll see.

Dynamic scriptable interfaces.  I thought of this.  I was actually going to
go down to the C++ level and look at vtables in order to dynamically resolve
methods.  In theory all I would need was an object reference (the data),
find the class it was associated to and do a vtable lookup.  In practice
this is hard to do which brought me to the same conclusion you have stated
here - using an interface.  This is sort of how Java does it.  The other way
(which is actually the same way but with automation built in) is to use the
SWIG toolset.  This is a nice way to get C++ objects into scripting
languages.  Check it out at www.swig.org.

On another note. I was just recently at the San Jose Linux World discussing
Bonobo (the GNOME object model) with one of the Helix Code developers.
Bonobo is built over Corba and from what I heard pretty fast once things are
binded.  The thing I wanted to find out was if we were reinventing the wheel
here.  My conclusion was that what we have is a fast and simple object model
that fits very easily into any C++ project (I in fact want to test it with
the plugin system for Half-Life bots to see if I can extend HL to run more
than one type of bot AI at a time).  All the other object models out there
are more or less for application development and tend to trade off speed and
simplicity for other factors. That is of course except Piers XPLC which has
similar but different goals than us. Of course we make trade-offs too. Such
things as in-process objects can cause an application to crash miserably if
a SOMEObject is coded bad where as Bonobo is out of process (each object
resides in its own process and communicates through ipc).  Well just some
things to think about as we figure out our goals.  Hopefully in the future
we can add bridges that allow for SOMEObject to be loaded from other object
models and visa versa.  Imagine gecko (Netscapes rendering engine) embedded
as a SOMEObject making it easy for people to use it without learning XPCOM.

John Palmieri

Re: [Somelib] Current design concept

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

Thomas Matelich wrote:

> Thomas Matelich wrote:
> >  I think this would eliminate the need for base classes, like Karl's did.

NOTE for those of you reading the archive who don't know about Karl's code, it
is another implementation which I could send you if so desired.

Back to my post.  I was being rather moronic with the whole "no base class"
thing.  That is impossible (took me a failed build to realize :).  I don't
know what I was thinking.  Karl's did have base classes just not a "SOME"
one.  So my current tack (I think), is to have no required base class for
SOMEObjects.  Interfaces/Parameters will be optionally specified in the
SOMEClassInfo (I think).

Of course, I could put some sort of interface functionality into a base class,
something like a map of strings to strings.  Base::setParam("name", value)?
The interface spec in SOMEClassInfo would have the names, descriptions, and
types.  We'll see.

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

Re: [Somelib] Current design concept

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

Thomas Matelich wrote:

> SOMEClassInfo - I'm not sure exactly how this class will work but it
> will contain the class name, a category/purpose, and (if possible, I
> think it is) functions for creating instances of the class.  I think
> this would eliminate the need for base classes, like Karl's did.

I've now decided that we need to support both paradigms.  The first way to
use SOMELib is for just loading "known" classes at runtime, either for
keeping footprints small or for simplicity of changing the system.

The other concept (which I'm more keen on) is use as a plugin library,
where you may have multiple types of functionality for a certain purpose.
This concept requires a base class to be used because we want variable
functionality to implemented with virtual functions.  My idea is that you
would use the category to specify what the class is supposed to do, and do
lookup based upon the category to see what base class to instantiate to.
Example: data filtering.  You would have a filter base class with a virtual
function to override for the actual filtering.  When a plugin is loaded
with a Filter category, you would create a SOMEObject of the base filter
type and use it to provide the special functionality.

So my next question is, what about parameters for plugins?  A smoothing
filter could require a number of iterations (int) and a smoothing factor
(float < 1) while a frequency filter would have a hi-pass and low-pass
freqs, or something.  How do we provide that capability?  Does it go in
SOMEClassInfo?  Do we use scripting somehow?  I don't know.

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

[Somelib] Current design concept

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

Here is the layout for what I'm currently working on, not all ideas have
been completely fleshed out.

BasicDynLib - an abstract base class for loading dynamic libraries.
Specific types (linux, windows, hpux, ...) are hidden from the user and
selected by defining the correct symbol in UserConfig.h.  BasicDynLib*
newDynLib() allocates the selected derived class.

SOMELibFactory - Manages loaded libraries.  Dynamic libraries must have
a function vector<SOMEClassInfo>& RegisterClasses() to return
information about classes available for use within the library.  This
will allow packaging of multiple classes within one library.

SOMEClassInfo - I'm not sure exactly how this class will work but it
will contain the class name, a category/purpose, and (if possible, I
think it is) functions for creating instances of the class.  I think
this would eliminate the need for base classes, like Karl's did.

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

[Somelib] testing 421

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

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