Re: [patch #6071] Resing/Deleting/Inserting variables in GUI

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Wed, Jul 11, 2007 at 09:56:23AM +0800, John Darrington wrote:
>
>      I see.  So unless we're going to somehow make the dictionary aware of
>      the capabilities of the data source with which it's associated (which
>      sounds like a nightmare to me) then we have to compromise.  However,
>      there may other advantages to keeping the case indices monotonic with
>      respect to the dict indices, and accepting the O(n) overhead of
>      dict_compact_values (or dict_pad_values) with every
>      insertion/deletion.
>
> The more I look at this, the more I realize how intertwined the issues
> are.  Unforunately, monotonicity is not something that we cannot 
> assume nor enforce.  [...]

I agree that monotonicity is something we cannot assume or
enforce in general.  But I do not think that the GUI is the
general case.  I think that it is one specific case that we can
deal with.  The fact that we can resize the data itself indicates
that the data must be coming from a datasheet, which is the only
data source that supports resizing data.  So I think that we
could maintain the dictionary's variable in the same order as the
datasheet's columns.  If we do so, then simply compacting the
dictionary after setting the variable width will have the same
effect as dict_pad_values/dict_var_resized.

Maybe I'm making a bad assumption somewhere here, please correct
me.
-- 
"Implementation details are beyond the scope of the Java virtual
 machine specification.  One should not assume that every virtual
 machine implementation contains a giant squid."
--"Mr. Bunny's Big Cup o' Java"