Re: [lmi] Product editor API: changing the axis dynamically

[Greg Chicares]

On 2005-10-19 17:03 UTC, Vadim Zeitlin wrote:
> On Tue, 18 Oct 2005 15:32:36 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I think I created some confusion by saying 'mutable' without first 
> defining
> GC> the intended sense. There are at least three possible senses:
> GC> 
> GC> (A) A hardcoded constant changes. Today, a program says
> GC>   int const N = 5;
> GC> and tomorrow the source changes to
> GC>   int const N = 6;
> GC> where N might be the number of axes or the number of enumerators for one
> GC> particular axis. The design has mutated: the source changed.
> GC> 
> GC> (B) A constant read at initialization changes. The number of axes and the
> GC> number of enumerators for each axis are read from a configuration file.
> GC> The file looks like this today:
> GC>   <axes>
> GC>     <axis name=fruit>
> GC>       <enumerator>apple</enumerator>
> GC>       <enumerator>pear</enumerator>
> GC>       <enumerator>banana</enumerator>
> GC>     </axis>
> GC>     <axis name=vegetable>
> GC>       <enumerator>carrot</enumerator>
> GC>   ...
> GC> and tomorrow we add an enumerator for another fruit, or add a new axis
> GC> for types of bread. The design has mutated: the configuration file 
> changed,
> GC> but the source code didn't. End users would be forbidden to change that
> GC> file. Only we could change it. Somehow, lmi would need to handle an axis
> GC> or enumerator added or removed this way; the advantage is that the 
> editor's
> GC> source code wouldn't need to change.
> 
>  Sorry for returning to this question, which I've previously said to be
> solved/decided, but more I think about it, more I wonder if the above is
> really doable/useful. I.e. is it really possible to add a new axis without
> changing the code? In theory it would seem that the answer is yes but in
> practice I'm really unsure how useful could this be.

For purposes of this discussion, let me speak of lmi and the editor as two
separate programs (though they could alternatively form one '.exe').

When axes or enumerators change, lmi source certainly must be modified.
My question is whether the editor's source needs to change. If possible
without too much work, it would seem really nice to make the editor
generic, and have it read axes and enumerators from, say, an xml file.

Now let's think about that. Changing the axes seems to be the harder
problem, because each axis has a checkbox or combobox or whatever.
In theory at least, we could say that the 'Duration' axis is special,
but all other axes are enumerative, so I guess the editor could read
them from an '.xrc' file. Oh, but, as you've pointed out, 'Issue Age'
is also a special axis--it's an integer range. So that complicates
things. Changing enumerators for an (enumerative) axis is probably
less difficult than changing an axis, but it still increases the
overall difficulty.

It sounds like a glorious idea, but there is glory also in compile-
time checks:

>  The problem is that I'd really like to have better compile-time checks
> that everything is consistent but it's impossible with this kind of
> flexibility so basically the API right now will operate with vectors of
> boost::any everywhere. I will put in run-time checks (asserts) everywhere,
> of course, but I still can't avoid thinking that having a template class
> which would fix the number and type of axis during compile-time could be
> better.

It's also important to consider ease of maintenance. At first, I
thought it would be easier to maintain if the editor didn't know
anything about the concrete axes or enumerators. At best, though,
that means that an xml file would need to be maintained instead of
the editor's source files. And, given that lmi's source must change
anyway when axes or enumerators change, perhaps it's best to have
lmi and the editor share a header containing enums or template
classes (or whatever) that would express all this information
only once.

I never really tried to solve this problem in 'ihs', lmi's OWL-based
predecessor with its integrated editor; or I never tried to solve it
well, to be more precise. There's a file 'dbnames.txt' in ihs (which
became 'dbnames.xpp' in lmi) that wishes it were xml (but is only a
ghastly parody of xml), and a corresponding header 'dbnames.hpp'
that repeats some of the same information as a C enum, with a
comment warning that the two files must be maintained in unison.
These are not among the files I'm most proud of.

Let me just leave the decision up to you. If you find a way to
factor all the axis and enumerator information into xml, then I'll
be able to use that as a guide to rewrite this part of lmi. If you
consider it better (e.g., because of the possibility of run-time
checks) to put that information in a source file, then I can use
that source file for xml. It's a difficult design question with no
obvious answer, but "that's why you make the big bucks" as a common
expression in this country puts it ("bucks" meaning dollars, not
male deer), and you can hardly do anything worse than I did in ihs.

>  Anyhow, if you could please just confirm once again that the possibility
> of determining the number and type of axis (as opposed to just determining
> the set of values for each axis) is really useful for lmi, I won't return
> back to this again but I'd like to have one final confirmation before
> abandoning the compile-time checking idea completely.

I am happy to trust your judgment.