octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: units conversion (was: about contibuting to octave)


From: Ben Abbott
Subject: Re: units conversion (was: about contibuting to octave)
Date: Thu, 12 Mar 2009 19:11:31 +0800


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", address@hidden, "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", address@hidden, "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", address@hidden, "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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]