units conversion (was: about contibuting to octave)

[Ben Abbott]

On Mar 12, 2009, at 6:13 PM, Michael Goffioul wrote:

> There exist already some code to convert from different "units".
> See for instance the convert_position function in graphics.cc used
> to convert position rectangles between various possible "units".
>
> Some extension is needed to be able to handle single point instead
> of rectangle and also to support data "units". However, the axes  
> object
> provides an easy access to the current transformation matrix, so it
> shouldn't be that hard.  ... (snip)

Regarding units conversion, should we write a single function that  
handles this job for all objects with a "units" property?

If we do that, it appears to me that we only need to write a single  
listener to handle to handle the conversion for all objects with  
"units" properties.

Actually, given how addlistener works, it should be possible to write  
a singled listener for everything (at least to have a single function  
name whose actions depends on the object "type" and the property  
changed).

For example, if the listener function is called "update_property", and  
takes the following inputs ...

	update_property (h, dummy_arg, property_that_changed,  
old_property_value)

The listeners for conversion of an object's units would be ...

	addlistener (h, "units", {@update_property, "units", get (gca,  
"units")})

The listener function would then have access to the new and old units  
as well as the old value.

The listener for objects with a "rotation" property ...

	addlistener (h, "rotation", {@update_property, "rotation"})

In this case the old value isn't needed.

The same approach can be used for objects with the "position" property.

	addlistener (h, "position", {@update_property, "position"})

One advantage of a unified listener is that it is easy to disable  
recursion. For example, changing "units" changes the "position"  
property, but need not trigger a new rendering.

I think this approach can handle all cases and sets a consistent  
standard that would make maintenance easier.

I'm thinking about this from the perspective of m-file implementation.  
However, as several properties are read-only, this would need to be  
implemented in c++. So, I may be off base in my approach.

Comments?

Ben