Re[2]: [lmi] Product editor API

[Vadim Zeitlin]

On Tue, 18 Oct 2005 15:32:36 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2005-10-18 13:15 UTC, Vadim Zeitlin wrote:
GC> > On Tue, 18 Oct 2005 02:46:29 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2005-10-18 0:21 UTC, Vadim Zeitlin wrote:
GC> > GC> > 
GC> > GC> >  I'm designing the API of the MultiDimGrid class (suggestions for 
better
GC> > GC> > names would be gratefully accepted) which is going to be used in the
GC> > GC> > product editor window and I have a couple of questions:
GC> > GC> > 
GC> > GC> > 1. I suppose we're going to have an arbitrary number N of axis 
(i.e. not
GC> > GC> >    limited nor fixed) and each axis can take different number of 
values.
GC> 
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> (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> (C) End users can change anything at run time. We don't want that.
GC> 
GC> Of these three, (A) would be meet our needs, but would be difficult to
GC> maintain; (B) would be best; and (C) is not wanted at all for lmi. I'm
GC> guessing that (B), the ideal, is practicable.

 Ok, we'll go for (B) then. It does simplify the choice of implementation
because, for example, it means that you can't make the data model a
template class (as this would fix it at compile-time). I thought of doing
this because it would provide better (compile-time instead of run-time)
checks but, of course, to be able to do compile-time checks you need to
define the axis during compile-time as well. So we'll do (B) and define
everything during run-time.


GC> > GC> lmi needs some small number of axes. Small, but mutable, not fixed.
GC> > 
GC> >  I thought the axis would be fixed but could be disabled/hidden at the GUI
GC> > level. I thought that changing the "cardinality" of the data model on the
GC> > fly probably wouldn't be a good idea. But maybe we could swap just the 
data
GC> > part of the control (e.g. when another item is selected in the tree).
GC> 
GC> End users can never add a new axis. They can disable axes that they
GC> don't want to use for a particular entity.
GC> 
GC> End users can't change the number of enumerators for an axis, with one
GC> important exception: they can change the number of 'Durations'. If an
GC> entity varies by 'Gender' and 'Duration', e.g.,
GC>   Gender: {Female, Male, Unisex}
GC>   Duration: [0..3]
GC> then they can change the upper 'Duration' this way
GC>   Duration: [0..5]

 This is an unwelcome (but, I realize, necessary) exception. Right now I
don't really see how to handle it in a generic way but I'll think more
about it...


GC> Explaining the rationale may make the design clearer.

[explanation snipped but thanks a lot for it, it does help!]


GC> > GC> >    The only question is whether these values can always be handled 
as
GC> > GC> >    strings or is it important to keep type information for them, 
i.e.
GC> > GC> >    also handle integer (and maybe real/float?) values?
GC> > ...
GC> > GC> Most axes are string-valued. Users would be baffled by integers: 
they'd
GC> > GC> struggle to remember whether 'Female' is 0, 1, or something else.
GC> > 
GC> >  Of course, we do need to have string values [too]. The question is 
whether
GC> > we want to have numeric values as well.
...
GC> So I think you're right, and thank you for continuing to question this.
GC> Design decisions made years ago have ossified, and it's become hard
GC> for me to think beyond them. But it really is better to use integers
GC> here, and a spin control would be more usable.

 I admit I didn't fully understand the reasoning which I snipped above
(I'll reread it again at a more sane hour) but intuitively it does seem to
me that it would be better to support integer axis, I just have a feeling
that it's the right thing to do so I'm very glad you finally arrived to the
same conclusion by better founded thought process.


 Things do seem to settle quite nicely, the only remaining problem is how
to treat "Duration". I'll write again when I have a solution for this,

 Thanks for taking time to write such a thoughtful reply!
VZ