|
From: Hans-Bernhard B. <HBB...@t-...> - 2009-01-04 17:46:05
|
Ethan A Merritt wrote: > [summary] The question is whether the code in get_data() > plot2d.c lines 327ff can be replaced by a table-lookup, > or deleted altogether. This code sets limits min_cols and max_cols > for the number of columns specified in the "using" part of a plot > command. That's not all that code does. And a table would fail to represent those other things. In short, I don't this hurts anywhere near bad enough to change it. > Ralf's proposed table would also hold properties like > PLOT_STYLE_HAS_FILL that are currently single bits set in the > line style definitions in gp_types.h I agree that that part would make sense. > As you move into that kind of question, I start to think that > the whole idea of a fixed set of properties for a given plot > type breaks down. Indeed. The original design has been thoroughly swamped under by new features. We're doing so much stuff outside (or in conflict with) the concept of plot styles that it's hard to see what it was originally meant to be: a complete description of how a given dataset would be displayed. And not a lot of that is described too well in the documentation, either... > It was this kind of argument that made me inclined to delete > all the code tracking min_cols and max_cols. Other than issuing > an error message if the command fails to provide at least min_cols > of using specs, they aren't much use for anything. Well, given that that's exactly what they're being computed for, why should they do more? > It may not even generate an error message if you exceed max_cols, as > you have already pointed out with regard to filledcurves. Now that would be bug. >> What >> aboutthe has_grid_topology property in struct surface_points? >> Is that not plot-style specific property? No. It's a feature of the data, not the plot style. Which is why it's in the data structure holding the dataset: struct surface_points. |