John Darrington <[EMAIL PROTECTED]> 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" _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
