Re: [guppi-list] Goose Design Problem & a Proposed Solution (long)

["Asger K. Alstrup Nielsen" <alstrup diku dk>]

> I've had very little time to devote to Goose recently, but I've been thinking
> a lot about it and I've come to the conclusion that some of the design
> needs some tweaking.
> 
> My concern is that we've gone to far in "OO-ifying" the interface.

[The common set of operations on DataSets is limited to container
handling, sorting and permuting.  Because the polymorphism is "simulated"
with a class hierarchy, this might introduce a bunch of switch-constructs 
when you use the DataSet.  So why not reduce the problem and use simple 
strings as the polymorph object?]

Could you try to describe what the problem with the current
solution is?

The problem of using strings, as I see it, is that you loose
security:  Instead of having type checking at compile time, you
end up having it at run-time.  (I realize that we do not solve
the problem completely with the class-hierarchy - some checking
is done at runtime as well.)

I'm not sure you solve the problem of switch-statements:  You
still need to handle the case where you pass a string that
don't parse as a real to a RealSet, and this handling is dependent
on the DataSet you are dealing with.

> Now the big problem with this is that it will break Asger's data
> importing stuff.  I hate doing this, but it seems unavoidable.  The
> good news is that I'm sure that the importer code will bounce back
> better than ever once we get our foundations in order...

The ascii import is general, and adapts very easily to other
set-ups, so don't worry about this.

The problem is that you haven't convinced me that we can
avoid in-elegant code with strings ;-)

Maybe there are some good reasons to get the Value and DataType
stuff out of the DataSets.  But the switching problem is not
enough to convince me.
Maybe there are problems with building a DataSet class hierarchy,
but let's have a look at those before we decide.  Maybe there
is a elegant solution after all.

The problem is that C++ does not support polymorphism in a good
way, unless you use templates.  However, the templates turned
out to be unusable at this point in time, so we can not
expect to find a beautiful solution to this problem.
I've searched high and low for a nice solution to this problem,
but as far as I can tell, it doesn't exist.  So we are left
with something that is sub-optimal, but at least we should try
to do as good as we can.
I have a feeling that simply using the strings as medium will be
a mistake, because we loose type safety.  I don't know if this is 
a real problem.

But I'm listening.

> I'll try to work on these changes in the next few days.  I've got a
> very big commit pending here already (I've added a ton of special
> functions stuff, moving all that code into a seperate shared library),
> so I might as well just make it bigger.

Personally, I'm studying for my exams that end the 25th.  After that,
I'll have some time to work on Goose.  However, in our project,
we have bumped into a serious problem:  Making a DLL out of Goose
in Windows is difficult, because the Visual C++ compiler is not
able to handle the static data that the STL needs.
So when we pass an STL structure to the DLL, data corruption occurs.
Microsoft proposes a solution where every exported method, and
every STL instance in the DLL, is marked with a special flag
to make it use static data from the linkee.  I think this solution
is undesirable.
So the only realistic solution is to link the library statically
into the binary, which is a piece of cake.
However this implies that we can't fulfill the LGPL.  The LGPL
requires you to allow people to upgrade the library to a newer
version without a need for a re-compile of the entire application.
And this is of course not possible with a statically linked library.

So this has unforeseen and unfortunate consequences for Goose on
Win32:  It can't be used in non-free applications after all, if 
you use Visual C++.

This is a serious problem for us.  The ultimate consequence could
be that we back out of the project, and only use the code that
I have written.  This would be very sad because I think both parties
benefit from the coorporation for reasons I explained last year.  
So I propose that you consider making an exception to the license:  
Until it is possible to build a DLL without poluting the source with tags, 
you grant us the right to statically link Goose into our project.
When the next version of Visual C++ is out, I hope they have
fixed the problem, and then we can revert to a raw LGPL.

I personally feel that such an exception to the license would be
of academic interest only:  It is not very realistic that somebody
would have a need to relink our application with a newer version
of Goose, and even if that should happen, we would of course
be willing to do it with any version they want instead.

Our lawyer says that it's questionable whether we would be in legal
trouble if we just statically linked the library without explicit
permission, because we can argue that it's not realistically 
possible to do it.  But this is not a satisfactory situation,
because morally we would be wrong.  (This is similar to the
KDE/Gnome debate:  It's not clear whether it's legally
illegal to link Qt with GPL software, but it's morally
wrong without question.)

(The linking problem is similar to template libraries:  Since all of the
code in such are in the header files, it's not technically
possible to relink a new version into an application, as the
LGPL requires you to be able to.  This implies that you can't
really find a GNU-style license that fits.  I know that the
Blitz++ people have run into this problem, and not really found a
solution yet.)

Greets,

Asger