Re: [Somelib] Another checkin

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

John Palmieri wrote:

> Scratch that.  I get it now.  A few items:
>
> Do you think that parameter constructors are necisary?   I always viewed them
> as convinence and they do dirty up the code a bit with the macros.  Also you
> are stuck with being able to construct parameterized constructors only if you
> have a macro that matches the number of parameters.  I have a sever dislike
> of macros ever since I tried to program for windows and wondered why they
> didn't just go the ANSI way.

The only macro functions in the program are the ones for generating boilerplate
object constructors.  I did it this way to simplify the life of the programmer.
Since we are looking for a function to call to return an object of some unknown
class type, we either need to use this macro, or enforce a function to be
present in the class, either by forcing our own base class or by convention and
using templates, oh wait, that wouldn't work because we don't know the type.  I
am strongly opposed to forcing a base class, through personal preference and our
goal to allow this to be easily dropped into a problem.  I don't see a problem
with these simple macros.

To address the multiple constructor issue, I must state that I love references.
Truly, I think they are the best thing since templates (though I'm not sure
which came first).  Anyway, the problem is that member references must be
initialized at construction, hence the need for providing the extra multiple
parameter constructor option.

> The Info class is a nice way to abstract things.  I quite liked it after I
> understood it.  It can be expanded in the future for use with dynamic
> interfaces.  I still think it can be automated.

I agree.  At this point (since I haven't learned Python yet), I haven't done so,
and don't think it will be done for a while.  If standard compliant compilers
were prolific, I would use some fancy template tricks for this.

> BasicPluginInterface should be a pure virtual class with no implementation in
> it. Kinda confused me when an interface has actual code in it.

I suppose the TestApp should be expanded to be more of a training tool, but at
this point it really is just my testbed.  I put the implementation in there for
my own security to make sure the virtual functions really were working.  I can
remove it, or make it pure and have an implementation.  Actually, I think thats
what I'll do.

> Also I belive the SOME_EXPORT macro can consume the extern "C" directive so
> that is no longer a worry of the developers.

I agree, I'll do that.

<pasted in from message title "One More Thing">
John Palmieri wrote:

> I hit send by accident.  The Info class should be implemented as a
> map(Or a vector of maps) rather than a vector so that extra info can be
> stored and retrived from this interface in the future.  I can see how
> dynamic interfaces may work now.

Do you mean like additions to the category info?  I'm assuming you're talking
about SOMEClassInfo (as opposed to SOMELibInfo).

> There is a stub file (perhaps defined in IDL) that exports all the
> symbols for the dynamic interface.  A preparser goes through this file
> and constructs the infoclass and adds a method someDynamicInterface(
> string method,  vector params ) to the implementation file.  This method
> is constructed of a bunch of if statement like so:
>
> int HelloWorld::someDynamicMethodCall( string method, vector params ){
>          //I'm not sure how we will do return types.  Perhaps void pointers.
>          method+= "_"+params.length(); //or whatever the method is.
>                                                           // Note that this
> signiture is only an example
>                                                           // we need to find a
> more unique value
>           if( method == "Print_1" ){  //Print method is called with 1
> parameter
>                  this->Print( dynamic_cast<string>params[0] );
>           } else {
>                  return DynamicInterface::NOSUCHMETHODERROR;
>           }
> }
>
> The infoclass will then have information about print and how many
> parameter and of what type this method takes.  All objects will inherit
> from DynamicInterface which exports the someDynamicMethodCall method and
> all error enumerations.  The Info class can now be used in an IDE to
> edit object properties and generate code much like JavaBeans.
>
> Just a thought.

This is a useful idea.  My problem is that this is not how *I* want to write my
code.  SOMELib to me is a handy, simple way to use plugin classes on multiple
architectures without having to go much out of your way.  Right now all that you
need to do to use this is write your interface, then put some derived classes in
a library with one macro after the class declaration and write a short function
to provide that info to the loading executable.  Implementing a preprocessor,
and forcing table creation is not my idea of a good time.

> I want our stuff to be compatable with the CoreLinux++ stuff so once we
> hammer the details out a bit we should pass it by them and see their
> thoughts on the subject.

Can you guess my response to this?  While CoreLinux is going to provide an
excellent framework for developing very flexible code, I am not the guy to use
it.  I haven't read the whole scheme, but the links that Frank sent scare me
(nothing personal).  I don't want to wrap my basic data types.  I want to write
plain code, using non-invasive libraries that provide a limited, very useful set
of functionality.  Compatibility is fine with me, but not dependence.

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