octave-maintainers
[Top][All Lists]
Advanced

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

Re: [Changeset]: Re: cla() ?


From: John W. Eaton
Subject: Re: [Changeset]: Re: cla() ?
Date: Fri, 10 Oct 2008 11:14:00 -0400

On 10-Oct-2008, Michael Goffioul wrote:

| On Wed, Oct 8, 2008 at 8:26 PM, John W. Eaton <address@hidden> wrote:
| > On  7-Oct-2008, Michael Goffioul wrote:
| >
| > | While we're talking about __go_delete__, does anybody
| > | remember what was the idea behind removing an object
| > | from its parent's children in __go_delete__, instead of
| > | gh_manager::free? This makes life slighlty more complex
| > | if you want to delete an object from C++, where you would
| > | typically use gh_manager::free, but you then have to remove
| > | the child manually from its parent's children.
| > |
| > | I don't think I wrote that part of the code, and I can't figure
| > | out why it is written that way.
| >
| > It's likely that I wrote it, and I assumed that a call to the delete
| > function should remove the handle from its parent's list of children.
| > Is that not what should happen?  If not, then what should happen?  For
| > example, what does Matlab do for
| >
| >  h = line (); get (gca (), 'children'), delete (h); get (gca (), 'children')
| >
| > ?  Shouldn't the children of the current axes be empty after H is
| > deleted?  If that doesn't happen automatically in the delete function,
| > then how does it happen?
| 
| It should definitely be removed from the children list, that's not the
| problem here. My question is why is that operation (== removing
| the handle from its parent's children) in __go_delete__ and not in
| gh_manager::free.

I think the reason I chose to do it this way is that I originally
thought of the gh_manager class as just a way to manage the handles
(generate new handle numbers, store deleted handle numbers in the free
list, etc.).  I thought it would be simpler that way.  If it would be
better to have the gh_manager class do more, then that's OK with me.

Likewise, if the title, xlabel, ylabel, and zlabel properties should
also be listed as children, then that's OK too.  I suppose I was
confused because they don't normally show up in the list of children,
and I did not know about the handlevisibility property.  In any case,
it seems they still need some special treatment because the handles
appear in both the list of children and as separate properties.

I'd certainly consider a patch for these changes, but I don't have
time to attempt it myself at the moment.

jwe


reply via email to

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