[Somelib] Direction

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

John Palmieri wrote:

> I made some major changes to SOMELib(see my last post).  Everything
> still compiles correctly but extra methods were added so everyone should
> do a cvs update.  I also added a new example "simplemenu" to illistrate
> the use of the new methods.  From now on when new functionality is added
> one of the examples should be updated to reflect this or new examples
> should be created.
>
> --Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

sounds good.  I'm working on getting things working on HPUX.  I meant to
write an email kind of explaining myself.  Essentially, I just don't want
this to turn into something where to do what we can now becomes difficult
and the discussions led me to feel that way.  As the suggestions whirled
around in my brain for a while, I came to grips with my problems.  I like
the idea of being able to provide extra info.  Limiting it to category
bothered me, but I hadn't gotten around to fixing it.

Let's list all the places I can think this can go, or has gone.  Also I'll
list my opinion on it:
1)  Load unknown classes:
    a) C++ classes on POSIX, Windows, HPUX - DONE
    b) Other Platforms
    c) Other Languages
2)  Selecting
    a) By Name DONE
    b) By classification DONE (almost, John's gone a long way)
3)  Properties
    a) defined only by the inheritance interface DONE
    b) a fixed IDL type specification
    c) dynamic, may be specified by plugin class
4)  Method invocation
    a) inheritance interface only - DONE
    b) A fixed IDL type specification - I just don't like this idea
    c) A dynamic "map" of functions like EJB(?) - I could maybe get into
this
    d) ?

Some further discussion:
1.b)  I don't have any other platforms.  I need to look into SourceForge's
compile farm.  Also, how does the GPL work, can I look at libtool and see
how they use other platforms or would that be illegal?
1.c)  A lot of work is being done in this area.  I won't rule it out, but I
don't think we should be ruling it out.

3.b) and 4.b)  I don't really like the idea of having a separate file and
preprocessor.  It just seems like an extra area for bugs and versioning
problems.

3.c) and 4.c)  I might be able to get into something like this as long as
we maintain.  This seems like something that would fit in with what Frank
said regarding builtin attribute accessing/mutating.  I'm with John (do you
prefer Quinticent?) in not liking macros and I've already talked about not
liking wrapping all my types, etc..  I'm envisioning something like

SOMEClassProperty:
    attribute or function

SOMEClassAttribute: public SOMEClassProperty
    read-only or writable

SOMEClassMethod: public SOMEClassProperty
    parameter specification, etc.

There are fancy STL/generic things we could use as well.  Well I need to
get to work.


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