[Xr] What happended to the idea of getting rid of the xrs argument?

[Bill Spitzak]

Is this dead or not? I still feel it would be a very good idea. I need to 
know what kind of outcome we can expect from this as it affects whether fltk 
will use Xr or not. If the argument is required then I must write a wrapper 
function for every Xr function, in which case I may as well retain 
back-compatability. If the xrs argument is deleted then I will change the 
interface to match Xr exactly, in the hope that program can really call Xr in 
the future.

The only real argument I heard for keeping the xrs argument is that this is 
more "object oriented" in that writing object.XrLine(...) is somehow useful 
and better than just writing XrLine(...).

Unfortunately I cannot see how Xr in it's current state helps this. It is 
extremely unlikely any object provided by a higher-level interface will be a 
subclass of XrState, because of the need to create light-weight and 
non-displayed objects and the need to port to non-Xr systems.

If you have a call that returns an "xrs object" then this is exaclty the same 
as the current situation, there is no real difference between typing 
x->XrFoo(...) and XrFoo(x,...).

The only way to implement the above in any reasonable way is to have the 
toolkit provide a wrapper for every Xr call, which means the toolkit must be 
rewritten for every Xr update. Also any possible implementation will probably 
be slowed by the addition of a "did I create the xrs, if not create it" test. 
If another method to create the xrs is added then the programming problem is 
exactly the same as for the non-xrs version.

In any case I am much more convinced this would be a very good idea and am 
anxious to find out if there is any chance it could or will happen.