From: Alan W. I. <ir...@be...> - 2002-11-09 17:09:54
|
On Sat, 9 Nov 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Currently we have a nonuniform mixture of API's for the way we pass 3D > > information to our 3D routines. > As for what an "uber-API" for these would look like, we can look at the API > for the fattest plcont/plshade plot calls we have and go from there. > [...](gulp). The shade plotter has the exclusion region that the contour plotter > is missing, so if that capability were added to the contourer the two could > share that in common. Possibly with the (*defined) argument changed to: > > void (*defined) (PLFLT, PLFLT, PLINT *, PLPointer), > PLPointer defined_data); > > as I mentioned some time back (but never got around to doing it). Thanks for these suggestions. > 'Course the real trick is to define simpler front-ends that do the job at hand 80%-95% of the time. So plshades() is a step in the right direction. Also the kx, lx, ky, ly args in the contour plotter are rarely exercised so I'd personally leave them out of a simpler general-purpose API (they were there in plplot 2.6 and I left them in). I never use those kx, lx, ky, ly limits so I also wouldn't mind personally if they went. > > I also firmly believe that preserving the existing API should be a priority, > except when dealing with relatively newly-added calls for which some period > of flux is to be expected. People use different versions of plplot on > different machines; you don't want them to be *too* afraid to upgrade. I understand your concerns here, but OTOH we shouldn't be afraid to change if there are compelling reasons to do so and we give plenty of warning to our users. Moving to a uniform API for passing 3D information to our 3D routines may already be compelling enough reason, but let's clinch the deal by making it the best API we can think of. So after the next release I will think hard about your suggestions, and also the nx(iy) or ny(ix) problem (see next post) to see what I can come up with. Alan |