Handle type object containing itself

Hello,

I am currently working on a class which should shorten development time for GUIDE application, hopefully I will be able to upload it later for everyone to use - for some reasons I can't share the code now.

The class automatically generates a figure with ui objects according to a template and then starts assigning the ui objects callbacks.

Later on a data source is assigned and loaded to the class.

The hard part is that I don't have the GUIDE handles structure and when I enter a callback I only have hObject and eventdata.

I want to also have access to my class instance. I don't want to use global variables or save/read .mat files so I thought maybe save it in the figure UserData and read it via hObject.Parent.UserData.

As I assigned it I saw a possible problem : The figure is one of the class properties so the class contains the figure and the figure contains the class in UserData, therefore - the class contains itself.

The class inherits for the handle superclass so...Maybe this is ok? Does a handle class behaves like pointers in C so all it does is storing addresses?

Thanks!

[Rik]

I hardly ever work with classes, so I can't answer your question, but I do have two questions of my own.

There isn't really something GUIDE specific about guidata. It just stores a variable with a figure. So what is your issue with the callback functions? Why are you able to get eventdata at runtime, but not the guidata?

And my second question: why stick to GUIDE in the first place? Its only advantage is the rapid prototyping. Why spend your time making it faster, instead of fundamentally improving it?

Also, AppDesigner is class based as well. What would be the main advantage of your hard work over AppDesigner? This sounds like a massive project, but I don't see how it is better than using pure Matlab or AppDesigner, can you expand on that point a bit?

[Dvir Haberman]

About the first question - let's say I assign the do_something_callback to a button which looks like this:

function out = do_something_callback(varargin)
    do_something
end

when I press the button varargin gets 2 objects - hObject and eventdata.

I have no Issue of using hObject.Parent to get the figure and thus all of the other controls handles but what I don't have is the handles structre which is a part of the auto-generated GUIDE funciton which I usually use to store additional data like the class object which I used to create this figure.

Currently the solution I found is to create an additional figure which is invisible and with a name which is a variation of the figure name. Then, put my object in the UserData.

when I'm in the callback it looks like this:

function out = do_something_callback(hObject, eventdata)
    parent_fig = hObject.Parent;
    invisible_fig = findobj('Name', ['Invisible_Fig' parent_fig.Name])
    my_class_obj = invisible_fig.UserData;
    ...
    do_something
    ...
end

This is kinda tedious and I also need to remember to assign the original figure DeleteFcn to also delete the invisible one but...it works.

As for the second question - I had commented about the advantage of using appdesigner but it's not my desicion, I'm just an employee (-:

[Adam]

Since you are using classes anyway wouldn't it make sense to have a class representing the whole UI and the callbacks attached to this class? This is what I have always done (and also what App Designer does). Then you have access to everything you want simply through the class itself.

[Rik]

Also, you can simply retrieve the handles struct with the line of code below. That is exactly what GUIDE does as well. (and callbacks don't have/need an output)

handles=guidata(hObject);

As per the documentation of guidata, it will look up the parent figure if you enter an object handle.

Answer 1

[Walter Roberson]

Handle classes do behave like pointers. It is legal for a chain of stored objects to eventually return back to the same class.

If it were not, then you would have to consider each different array size of each data type to be a different class: e.g., class double_empty has operation extract_empty that returns class double_empty; class double_length_1 has operation extract_empty that returns class double_empty, and operation extract_length_1 that returns class double_length_1; class double_length_2 has operation extract_empty that returns class double_empty, operation extract_length_1 that returns class double_length_1, operation extract_length_2 that returns double_length_2, and so on. Trying to apply extract_length_1 operation to class double_empty is a type mistake not a run-time mistake when you are being pure about classes.

It gets pretty sad in theoretical terms. For example, class double_length_4 has to have these operations:

constructor double_length_4(double_empty, double_length_4)
constructor double_length_4(double_length_1, double_length_3)
constructor double_length_4(double_length_2, double_length_2)
constructor double_length_4(double_length_3, double_length_1)
constructor double_length_4(double_length_4, double_empty)

in order to handle concatenation resulting in length 4 in a system that insists on type purity. Each permitted resulting length has to have a separate method for each pairwise combinations of lengths that give that resulting length.

This is obviously not practical in general purpose programming languages. It does have some advantages in automated proofs, such as proving that a very strictly written system cannot produce an index-out-of-range.

Such type-safe systems cannot handle arrays of indefinite size: they have to have a maximum size that they are responsible for reasoning about.

If you think about it, MATLAB has type limits for arrays: arrays cannot exceed 2^48-1 elements in size (documented somewhere or other); and really arrays cannot exceed 2^48-1 bytes, because the x64 architecture has only been implemented on a maximum of 48 address lines (a fact that implementations have been permitted to take advantage of historically.)

[Dvir Haberman]

Thanks!

[Guillaume]

To the question "Does a handle class behaves like pointers in C so all it does is storing addresses", as Walter said: yes, a handle is just a pointer.

Now, for managed languages (e.g. matlab, Java, C#), you still have to be careful about objects storing references/pointers/handles to themselves. Typically, a memory manager will destroy the object once there's nothing left referencing it. The circular reference may prevent the manager from ever destroying the object, hence resulting in memory leaks. Some memory managers are clever enough to detect that sort of circular reference and destroy the objects when it's the only reference left. Matlab's memory manager is undocumented and I can't recall if it's one that can detect these circular references.

In the case of figures, matlab forcefully destroy the figure object when the figure is closed (regardless of whether handles to it still exist), so it's not a problem, but for your own classes it may be something to bear in mind.