[Top][All Lists]

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

Re: handle grapics with Document/View design

From: John W. Eaton
Subject: Re: handle grapics with Document/View design
Date: Fri, 14 Oct 2005 12:37:40 -0400

On 14-Oct-2005, Paul Kienzle wrote:

| On Oct 14, 2005, at 5:01 AM, John W. Eaton wrote:
| > Since the list of graphics objects is just a global variable, I think
| > we will need some way to prevent a user from wiping it out.
| Using a persistent variable in a locked function is one strategy:
|    function retL = uiobjects(newL)
|      mlock
|      persistent L={};
|      if nargin == 1, L = newL; end
|      retL = L;

Yes, I thought about doing that, but it was simpler to give several
functions direct access to this data rather than just one.  OTOH,
since Octave allows you to index the result of a function call
directly, there isn't much difference between a global variable and a
persistent variable managed this way if all you want is read-only
access.  For setting the value, you have to write something like

  uiobjects (uiobjects.field = new_value);

instead of just

  uiobjects.field = new_value;

So all this does is prevent you from clearing the structure.  I think
what we really want is some way to have persistent data that is shared
among several functions (but limited to only those functions) and that
can't be cleared.  For that, I think we need private functions.

In any case, all the internal objects and functions currently have
names like __uiobject_XXX__.  You are not supposed to touch symbols
with names like that.  There is no way to enforce that rule, but if
you play with power tools, then you can easily hurt yourself.

If this turns out to be a probelm, we can use an approach like the one
above, possibly along with private functions (which need to be
implemented).  Having private functions would help for this code


reply via email to

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