Handle type object containing itself
5 visualizzazioni (ultimi 30 giorni)
Mostra commenti meno recenti
Dvir Haberman
il 28 Lug 2019
Commentato: Rik
il 29 Lug 2019
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!
4 Commenti
Adam
il 29 Lug 2019
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
il 29 Lug 2019
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.
Risposta accettata
Walter Roberson
il 28 Lug 2019
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.)
2 Commenti
Guillaume
il 29 Lug 2019
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.
Più risposte (0)
Vedere anche
Categorie
Scopri di più su Specifying Target for Graphics Output in Help Center e File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!