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

[Jon Trowbridge <trow emccta com>]

On Tue, Jan 19, 1999 at 12:02:46PM +0100, Asger K. Alstrup Nielsen wrote:
> 
> Could you try to describe what the problem with the current
> solution is?

The main problem that I'm having right now is that the current scheme
doesn't generalize in a clean way to handle categorical data.

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

Yes, but we still need run-time checks when you use the Value
framework.  To pick an example, the RealSet will (more or less) have
two ways to insert values: insert(double) and insert(string).
The first gives a compile-time check.  For the second, you might get
a string containing garbage, and then you throw an exception --- so
this is a run-time check.

But RealSet already has two ways to insert: insert(double) and
insert(Value).  If you pass a String Value into insert, or some other
invalid type, you throw an exception.  This is also a run-time check.

The reason types were ever introduced originally in Goose was to
provide a convenient mechanism for people writing data browsers, GUIs,
etc. so that they could move string reps of data in and out of a
DataSet without having to worry to much about what the strings
contained.  By going to strings, we go back to solving this problem
directly.  With Values, I feel like we are adding complexity to solve
some other, more general, problem... a problem that I'm not sure we
really need to solve.

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

The DataSet can throw an "invalid string format" exception.  With
values, you'd have to throw an "invalid value" exception.

Let me say a few more words on why Values bug me.  In categorical
data, we need to map strings to code numbers and back.  So a
"categorical value" is basically an integer, which is associated to a
string.  But for every different category, we need some sort of
"categorical value factory", and we end up with the Value and the
ValueFactory coupled in some way, because instances of the Value class
need to be able to do the int <-> string conversions.  And this
coupling is particularly vexing because I don't feel like we are
gaining a lot in exchange for this complexity...

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

Good.  I'm hoping that the new scheme could (at least potentially)
make import-type code simpler.  We'll see...
> 
> 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...
> <description of stupid broken compiler behavior deleted>

Ugh.  Well, we'll figure this all out one way or another...

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

I thought I heard something about RMS working on a new version of the
(L)GPL, which addresses issues like templates.  I could be
misremembering wildly, though...