Re: [RFC] introduce new routine draw_clip_arrow()

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> This is actually a reduction in the number of global variables.

Only at the outermost level. There's no change to the number of
individual global status variables, nor to their total size, by packing
things in structs.  It's a null-sum game.

But storing globals in special storage to replace their values by 
something else, for the duration of one function call, is still 
atrocious, which should be avoided by

1) passing the relevant thing in as a parameter
2) having the routine use its own global status, which you set as
    needed before calling it.

I'm against 2) because it again increases the number and size of
globals.

>>Please consider making the clip area to be used a parameter  
>>of draw_clip_arrow.

> This would not reduce the requirement for a global pointer, 
> unless the lower level clipping routines clip_point() and clip_line()
> were also modified to take an extra parameter.  

Well, refactoring can be done a bit more builtin intelligently than 
that: one could split these up into an actual engine holding a modified
version of the current clip_line()'s code:

	clip_line_actually()

and make a new clip_line like this:

	clip_line(parameters...) {
		clip_line_actually(&global_bounds, parameters...)
	}

No interface change to the outside, but new code can use 
clip_line_actually() if it doesn't want to use the global default
bounding box.

> Here again I agree in principle, but that would mean reworking
> all the existing lower-level clipping routines as well.

Not necessarily.  Just duplicate them and have them take coordval's.