lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vadim Zeitlin
Subject: Re[2]: [lmi] Product editor API: changing the axis dynamically
Date: Wed, 19 Oct 2005 19:03:53 +0200

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.

 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.

 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.

 Thank you,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]