{"id":748,"date":"2013-07-23T09:32:15","date_gmt":"2013-07-23T14:32:15","guid":{"rendered":"https:\/\/blogs.mathworks.com\/loren\/?p=748"},"modified":"2017-03-27T19:17:07","modified_gmt":"2017-03-28T00:17:07","slug":"deconstructing-destructors","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/loren\/2013\/07\/23\/deconstructing-destructors\/","title":{"rendered":"Deconstructing Destructors"},"content":{"rendered":"\r\n<div class=\"content\"><!--introduction--><p>I'm pleased to introduce guest blogger Jennifer Black, manager of the MATLAB object system team.  Today Jennifer will be sharing some thoughts on what happens when objects are destroyed in MATLAB and how you can control aspects of this process.<\/p><!--\/introduction--><h3>Contents<\/h3><div><ul><li><a href=\"#ca8f4c98-2a24-4451-90e6-917a12dd0d7e\">Why Define a Destructor<\/a><\/li><li><a href=\"#bd43b220-ac77-4515-b37a-8268049e442d\">Defining a Destructor<\/a><\/li><li><a href=\"#75ef4148-14f6-4de3-9499-bf8007c20cf5\">Calling Destructors<\/a><\/li><li><a href=\"#68a7e6b3-51c8-425b-bee4-efe665b1445c\">Handles Contained within Other Structures<\/a><\/li><li><a href=\"#67e23b2f-71a3-40be-96c6-74d708de2227\">Classes in Hierarchies<\/a><\/li><li><a href=\"#8c4529d9-8a59-49d2-a265-4a2172c817fe\">How Do You Use Destructors?<\/a><\/li><\/ul><\/div><h4>Why Define a Destructor<a name=\"ca8f4c98-2a24-4451-90e6-917a12dd0d7e\"><\/a><\/h4><p>When an instance of a class is cleared, MATLAB automatically cleans up the values of the properties owned by that object.  For example, if I have a <tt>Signal<\/tt> class with a property that stores a matrix of double values, that matrix is destroyed when a <tt>Signal<\/tt> is destroyed. Sometimes, however, additional actions might be needed to handle external resources.<\/p><p>Let&#8217;s consider the following class:<\/p><pre class=\"codeinput\">type <span class=\"string\">FileReader1<\/span>\r\n<\/pre><pre class=\"codeoutput\">\r\nclassdef FileReader1 &lt; handle\r\n    properties\r\n        FileID\r\n    end\r\nend\r\n\r\n<\/pre><p>In MATLAB, a file identifier is an integer returned by the <a href=\"https:\/\/www.mathworks.com\/help\/matlab\/ref\/fopen.html\">fopen<\/a> function. It is used by file I\/O functions such as <a href=\"https:\/\/www.mathworks.com\/help\/matlab\/ref\/fread.html\">fread<\/a> and <a href=\"https:\/\/www.mathworks.com\/help\/matlab\/ref\/fwrite.html\">fwrite<\/a> to access the file.  If fopen cannot open the file, it returns -1.<\/p><p>If I have an open <tt>FileReader<\/tt> named <tt>reader<\/tt> in my workspace, clearing <tt>reader<\/tt> will cause MATLAB to clear the value stored in my <tt>FileID<\/tt> property.  Now the number is gone, but the file is still open.  Clearing <tt>FileID<\/tt> without first closing the file means the file is left open even though it is no longer being used.  If this happens enough times I might run out of system file handles.<\/p><p>Let's look at defining a destructor to close the file handle. A destructor is a method of a class responsible for cleaning up resources owned by objects. In MATLAB, the handle superclass is used for all kinds of objects that have a unique identity independent of their current state.  Unlike numbers, matrices, etc., handle objects represent unique things that have a beginning and an end and may change internal state along the way. Any subclass of <tt>handle<\/tt> may define a special method named <tt>delete<\/tt>, often referred to as a destructor.  In the case of my <tt>FileReader<\/tt> class, I can correct the problem of leaking file handles by implementing my own destructor:<\/p><pre class=\"codeinput\">type <span class=\"string\">FileReader2<\/span>\r\n<\/pre><pre class=\"codeoutput\">\r\nclassdef FileReader2 &lt; handle\r\n    properties\r\n        FileID\r\n    end\r\n    methods\r\n        function delete(readerObj)\r\n            fclose(readerObj.FileID);\r\n        end\r\n    end\r\nend\r\n\r\n<\/pre><h4>Defining a Destructor<a name=\"bd43b220-ac77-4515-b37a-8268049e442d\"><\/a><\/h4><p>A MATLAB destructor takes a single input argument - the object being destroyed - and returns no outputs.  The input object is always scalar even if an array of MATLAB objects goes out of scope all at once.<\/p><p>In a MATLAB class you can define a method named <tt>delete<\/tt> that is not a destructor.  A <tt>delete<\/tt> method with a different signature is not a destructor, nor is a static <tt>delete<\/tt> method.  For example, defining the method to take more than one input argument or to return any output arguments means the method is not treated as an object destructor.<\/p><h4>Calling Destructors<a name=\"75ef4148-14f6-4de3-9499-bf8007c20cf5\"><\/a><\/h4><p>An object destructor can be called either explicitly by calling the <tt>delete<\/tt> method, or implicitly by MATLAB, for example when a variable is cleared or goes out of scope.  Let's consider the difference between these two actions.  To do so I will add a constructor and a <tt>readData<\/tt> method to my class:<\/p><pre class=\"codeinput\">type <span class=\"string\">FileReader3<\/span>\r\n<\/pre><pre class=\"codeoutput\">\r\nclassdef FileReader3 &lt; handle\r\n    properties(SetAccess = protected)\r\n        FileID = -1;\r\n        FileName\r\n    end\r\n\r\n    methods\r\n        function reader = FileReader3(fname)\r\n            if ischar(fname)\r\n                reader.FileName = fname;\r\n                reader.FileID = fopen(fname,'r');\r\n            end\r\n        end\r\n      \r\n        function colorData = readData(reader)\r\n            if reader.FileID == -1\r\n                error('No file name has been specified for this FileReader.  No data will be read.');\r\n            else\r\n                colorData = fscanf(reader.FileID,'%f',[3,inf]);\r\n                colorData = colorData';\r\n                frewind(reader.FileID);\r\n            end\r\n        end\r\n        \r\n        function delete(reader)\r\n            if reader.FileID ~= -1\r\n                s = sprintf('Closing %s', reader.FileName);\r\n                disp(s);\r\n                fclose(reader.FileID);\r\n            end\r\n        end\r\n    end\r\nend\r\n\r\n<\/pre><p>First, let's consider the case where I have one variable holding a <tt>FileReader<\/tt>:<\/p><pre class=\"codeinput\">myReader = FileReader3(<span class=\"string\">'colorData.txt'<\/span>);\r\n<\/pre><p>Explicitly calling <tt>delete<\/tt> on <tt>myReader<\/tt> invokes the destructor and then destroys the <tt>FileReader<\/tt>.  The <tt>myReader<\/tt> variable remains in my workspace, but its handle is no longer valid:<\/p><pre class=\"codeinput\">delete(myReader);\r\n<\/pre><pre class=\"codeoutput\">Closing colorData.txt\r\n<\/pre><pre class=\"codeinput\">isvalid(myReader)\r\n<\/pre><pre class=\"codeoutput\">ans =\r\n     0\r\n<\/pre><p>An implicit call to a destructor will occur if I clear <tt>myReader<\/tt> from my workspace:<\/p><pre class=\"codeinput\">myReader = FileReader3(<span class=\"string\">'colorData.txt'<\/span>);\r\nclear <span class=\"string\">myReader<\/span>\r\n<\/pre><pre class=\"codeoutput\">Closing colorData.txt\r\n<\/pre><p>The destructor will also be implicitly called if my variable goes out of scope, for example because the end of a function has been reached.  To illustrate, let's add a helper function in which I create a <tt>FileReader<\/tt>:<\/p><pre class=\"codeinput\">type <span class=\"string\">readDataFromFile<\/span>\r\n<\/pre><pre class=\"codeoutput\">\r\nfunction colorData = readDataFromFile(filename)\r\n    myReader = FileReader3(filename);\r\n    colorData = readData(myReader);\r\nend\r\n<\/pre><p>When I call my new helper function, <tt>myReader<\/tt> is created in the function and will go out of scope when the function ends.  This causes MATLAB to clear the variable, which results in an implicit call to the <tt>delete<\/tt> method:<\/p><pre class=\"codeinput\">colordata = readDataFromFile(<span class=\"string\">'colorData.txt'<\/span>);\r\n<\/pre><pre class=\"codeoutput\">Closing colorData.txt\r\n<\/pre><p>Now, let's contrast what we have just discussed about having a single handle with the case where I have multiple handles to the same <tt>FileReader<\/tt>.  This happens, for example, when I create a handle object and then assign that handle to another workspace variable:<\/p><pre class=\"codeinput\">reader1 = FileReader3(<span class=\"string\">'colorData.txt'<\/span>);\r\nreader2 = reader1;\r\n<\/pre><p>With these two handles to the same <tt>FileReader<\/tt> now in my workspace, I will explicitly call <tt>delete<\/tt>, and then use the <tt>isvalid<\/tt> method to see what happened to the <tt>FileReader<\/tt> object:<\/p><pre class=\"codeinput\">delete(reader1);\r\n<\/pre><pre class=\"codeoutput\">Closing colorData.txt\r\n<\/pre><pre class=\"codeinput\">isvalid(reader1)\r\n<\/pre><pre class=\"codeoutput\">ans =\r\n     0\r\n<\/pre><pre class=\"codeinput\">isvalid(reader2)\r\n<\/pre><pre class=\"codeoutput\">ans =\r\n     0\r\n<\/pre><p>As expected, the <tt>reader1<\/tt> handle is no longer valid, but note that <tt>reader2<\/tt> is also no longer valid.  Why did this happen?  Because when I explicitly call <tt>delete<\/tt>, the destructor is called and the object is destroyed no matter how many handles there are referencing that object.<\/p><p>Now let's see what happens when a destructor is called implicitly.  Once again let's create two handles to the same <tt>FileReader<\/tt>:<\/p><pre class=\"codeinput\">reader1 = FileReader3(<span class=\"string\">'colorData.txt'<\/span>);\r\nreader2 = reader1;\r\n<\/pre><p>But this time, rather than call the destructor explicitly, I will just clear one of the handles.  As we saw earlier, this can result in an implicit call to the <tt>delete<\/tt> method:<\/p><pre class=\"codeinput\">clear <span class=\"string\">reader1<\/span>;\r\nisvalid(reader2)\r\n<\/pre><pre class=\"codeoutput\">ans =\r\n     1\r\n<\/pre><p>Why is <tt>reader2<\/tt> still valid, and why was my destructor not called? Because MATLAB will only implicitly call a destructor when the <b>last<\/b> reference to an object is cleared.  As <tt>reader2<\/tt> still exists in my workspace, the underlying <tt>FileReader<\/tt> is not destroyed.<\/p><p>Most often a destructor is defined as a public method, but it can also be declared as a private or protected method.  Making it private will prevent code outside the class from explicitly calling the destructor. Similarly, a protected destructor can only be explictly called from methods of the same class or from subclass methods.  MATLAB will always be able to implicitly call a destructor, even one declared private or protected.  You might choose to restrict access to your destructor in a situation where you want to prevent the accidental deletion of an object, such as when you have a singleton object.<\/p><h4>Handles Contained within Other Structures<a name=\"68a7e6b3-51c8-425b-bee4-efe665b1445c\"><\/a><\/h4><p>What happens when a handle is stored as a field of a struct or a cell of a cell array, or as a property of another object?  When that top-level container variable is destroyed, the handle object will also be destroyed and its <tt>delete<\/tt> method implicitly called if and only if no other references to the object exist.  Let's look at an example with structs:<\/p><pre class=\"codeinput\">s.myReader = FileReader3(<span class=\"string\">'colorData.txt'<\/span>);\r\nclear <span class=\"string\">s<\/span>\r\n<\/pre><pre class=\"codeoutput\">Closing colorData.txt\r\n<\/pre><p>Note that the <tt>FileReader<\/tt> stored in the <tt>myReader<\/tt> field of <tt>s<\/tt> has been destroyed.  However, as we saw previously, another handle to the same <tt>FileReader<\/tt> will prevent the destruction of the object:<\/p><pre class=\"codeinput\">reader4 = FileReader3(<span class=\"string\">'colorData.txt'<\/span>);\r\ns.myReader = reader4;\r\nclear <span class=\"string\">s<\/span>\r\nisvalid(reader4)\r\n<\/pre><pre class=\"codeoutput\">ans =\r\n     1\r\n<\/pre><p>Even after clearing <tt>s<\/tt>, we see that <tt>reader4<\/tt> is still valid.  The second handle prevented the implicit destruction of the object.<\/p><h4>Classes in Hierarchies<a name=\"67e23b2f-71a3-40be-96c6-74d708de2227\"><\/a><\/h4><p>So far we have been looking at examples of stand-alone classes, but what about classes that are part of a hierarchy?  In MATLAB, every class has the ability to control its own destruction behavior.  In a hierarchy of classes, every class can define its own destructor.  As a result, a destructor cannot be defined as a <tt>Sealed<\/tt> method.<\/p><p>When an object is destroyed, MATLAB will call the destructor of the class of the object first, if it has been defined.  Next, the destructor of each superclass is called, starting with the most direct superclass.<\/p><p>A destructor can reference the properties of the class itself, including properties inherited from superclasses, but it generally should not reference properties of a subclass.  Why?  Because when a superclass destructor is executing, the destructor of its subclass has already executed, and could have invalidated the values in its properties.<\/p><h4>How Do You Use Destructors?<a name=\"8c4529d9-8a59-49d2-a265-4a2172c817fe\"><\/a><\/h4><p>Now that we've discussed the basics of working with destructor methods in MATLAB, I'd like to hear of your experiences. Are you already using destructors?  If you have any interesting applications or questions, I'd be very happy to hear about them <a href=\"https:\/\/blogs.mathworks.com\/loren\/?p=748#respond\">here<\/a>.<\/p><script language=\"JavaScript\"> <!-- \r\n    function grabCode_e4457c9de1124805ad16ce155c11c77c() {\r\n        \/\/ Remember the title so we can use it in the new page\r\n        title = document.title;\r\n\r\n        \/\/ Break up these strings so that their presence\r\n        \/\/ in the Javascript doesn't mess up the search for\r\n        \/\/ the MATLAB code.\r\n        t1='e4457c9de1124805ad16ce155c11c77c ' + '##### ' + 'SOURCE BEGIN' + ' #####';\r\n        t2='##### ' + 'SOURCE END' + ' #####' + ' e4457c9de1124805ad16ce155c11c77c';\r\n    \r\n        b=document.getElementsByTagName('body')[0];\r\n        i1=b.innerHTML.indexOf(t1)+t1.length;\r\n        i2=b.innerHTML.indexOf(t2);\r\n \r\n        code_string = b.innerHTML.substring(i1, i2);\r\n        code_string = code_string.replace(\/REPLACE_WITH_DASH_DASH\/g,'--');\r\n\r\n        \/\/ Use \/x3C\/g instead of the less-than character to avoid errors \r\n        \/\/ in the XML parser.\r\n        \/\/ Use '\\x26#60;' instead of '<' so that the XML parser\r\n        \/\/ doesn't go ahead and substitute the less-than character. \r\n        code_string = code_string.replace(\/\\x3C\/g, '\\x26#60;');\r\n\r\n        copyright = 'Copyright 2013 The MathWorks, Inc.';\r\n\r\n        w = window.open();\r\n        d = w.document;\r\n        d.write('<pre>\\n');\r\n        d.write(code_string);\r\n\r\n        \/\/ Add copyright line at the bottom if specified.\r\n        if (copyright.length > 0) {\r\n            d.writeln('');\r\n            d.writeln('%%');\r\n            if (copyright.length > 0) {\r\n                d.writeln('% _' + copyright + '_');\r\n            }\r\n        }\r\n\r\n        d.write('<\/pre>\\n');\r\n\r\n        d.title = title + ' (MATLAB code)';\r\n        d.close();\r\n    }   \r\n     --> <\/script><p style=\"text-align: right; font-size: xx-small; font-weight:lighter;   font-style: italic; color: gray\"><br><a href=\"javascript:grabCode_e4457c9de1124805ad16ce155c11c77c()\"><span style=\"font-size: x-small;        font-style: italic;\">Get \r\n      the MATLAB code <noscript>(requires JavaScript)<\/noscript><\/span><\/a><br><br>\r\n      Published with MATLAB&reg; R2013a<br><\/p><p class=\"footer\"><br>\r\n      Published with MATLAB&reg; R2013a<br><\/p><\/div><!--\r\ne4457c9de1124805ad16ce155c11c77c ##### SOURCE BEGIN #####\r\n%% Deconstructing Destructors\r\n% I'm pleased to introduce guest blogger Jennifer Black, manager of the\r\n% MATLAB object system team.  Today Jennifer will be sharing some thoughts\r\n% on what happens when objects are destroyed in MATLAB and how you can \r\n% control aspects of this process.  \r\n\r\n%% Why Define a Destructor\r\n% When an instance of a class is cleared, MATLAB automatically cleans up the\r\n% values of the properties owned by that object.  For example, if I have a \r\n% |Signal| class with a property that stores a matrix of double values,\r\n% that matrix is destroyed when a |Signal| is destroyed.\r\n% Sometimes, however, additional actions might be needed to handle external\r\n% resources.  \r\n%  \r\n% Let\u00e2\u20ac\u2122s consider the following class:\r\n%%\r\ntype FileReader1\r\n%%\r\n% In MATLAB, a file identifier is an integer returned by the \r\n% <https:\/\/www.mathworks.com\/help\/matlab\/ref\/fopen.html fopen> function. \r\n% It is used by file I\/O functions such as \r\n% <https:\/\/www.mathworks.com\/help\/matlab\/ref\/fread.html fread> and\r\n% <https:\/\/www.mathworks.com\/help\/matlab\/ref\/fwrite.html fwrite> to access\r\n% the file.  If fopen cannot open the file, it returns -1. \r\n%\r\n% If I have an open |FileReader| named |reader| in my workspace, \r\n% clearing |reader| will cause MATLAB to clear the value stored\r\n% in my |FileID| property.  Now the number is gone, but the file is still \r\n% open.  Clearing |FileID| without first closing \r\n% the file means the file is left open even though it is no longer being \r\n% used.  If this happens enough times I might run out of system file \r\n% handles.  \r\n%\r\n% Let's look at defining a destructor to close the file handle.  \r\n% A destructor is a method of a class\r\n% responsible for cleaning up resources owned by objects.\r\n% In MATLAB, the <https:\/\/www.mathworks.com\/help\/matlab\/ref\/handle.html handle> \r\n% superclass is used for all kinds of objects that\r\n% have a unique identity independent of their current state.  Unlike \r\n% numbers, matrices, etc., handle objects represent unique things that\r\n% have a beginning and an end and may change internal state along the way.\r\n% Any subclass of |handle| may define a special method named |delete|, \r\n% often referred to as a destructor.  In the case of my |FileReader| class, \r\n% I can correct the problem of leaking file handles by implementing my own \r\n% destructor:\r\n%%\r\ntype FileReader2\r\n%% Defining a Destructor\r\n% A MATLAB destructor takes a single input argument - the object being\r\n% destroyed - and returns no outputs.  The input object is always scalar\r\n% even if an array of MATLAB objects goes out of scope all at once. \r\n%\r\n% In a MATLAB class you can define a method named |delete| that is not a\r\n% destructor.  A |delete| method with a different signature is not a\r\n% destructor, nor is a static |delete| method.  For example, defining the\r\n% method to take more than one input argument or to return any output\r\n% arguments means the method is not treated as an object destructor.\r\n\r\n%% Calling Destructors\r\n% An object destructor can be called either explicitly by calling\r\n% the |delete| method, or implicitly by MATLAB, for example\r\n% when a variable is cleared or goes out of scope.  Let's consider the \r\n% difference between these two actions.  To do so I will add a constructor\r\n% and a |readData| method to my class:\r\n%%\r\ntype FileReader3\r\n%%\r\n% First, let's consider the case where I have one variable holding a\r\n% |FileReader|:\r\n\r\n%%\r\nmyReader = FileReader3('colorData.txt');\r\n%%\r\n% Explicitly calling |delete| on |myReader| invokes the destructor and then\r\n% destroys the |FileReader|.  The |myReader| variable remains in my\r\n% workspace, but its handle is no longer valid:\r\n\r\n%%\r\ndelete(myReader);\r\n%%\r\nisvalid(myReader)\r\n%%\r\n% An implicit call to a destructor will occur if I clear |myReader| from my\r\n% workspace:\r\n\r\n%%\r\nmyReader = FileReader3('colorData.txt');\r\nclear myReader\r\n%%\r\n% The destructor will also be implicitly called if my variable goes out of\r\n% scope, for example because the end of a function has been reached.  To\r\n% illustrate, let's add a helper function in which I create a |FileReader|:\r\n\r\n%%\r\ntype readDataFromFile\r\n%%\r\n% When I call my new helper function, |myReader| is created in\r\n% the function and will go out of scope when the function ends.  This causes\r\n% MATLAB to clear the variable, which results in an implicit call to the\r\n% |delete| method:\r\n\r\n%%\r\ncolordata = readDataFromFile('colorData.txt');\r\n%%\r\n% Now, let's contrast what we have just discussed about having a single\r\n% handle with the case where I have multiple handles to the same\r\n% |FileReader|.  This happens, for example, when I create a handle object \r\n% and then assign that handle to another workspace variable:\r\n\r\n%%\r\nreader1 = FileReader3('colorData.txt');\r\nreader2 = reader1;\r\n%%\r\n% With these two handles to the same |FileReader| now in my workspace, I\r\n% will explicitly call |delete|, and then use the |isvalid| method to see\r\n% what happened to the |FileReader| object:\r\n\r\n%%\r\ndelete(reader1);\r\n%%\r\nisvalid(reader1)\r\n%%\r\nisvalid(reader2)\r\n%%\r\n% As expected, the |reader1| handle is no longer valid, but note that\r\n% |reader2| is also no longer valid.  Why did this happen?  Because when I\r\n% explicitly call |delete|, the destructor is called and the object is\r\n% destroyed no matter how many handles there are referencing that object.\r\n%\r\n% Now let's see what happens when a destructor is called implicitly.  Once \r\n% again let's create two handles to the same |FileReader|:\r\n\r\n%%\r\nreader1 = FileReader3('colorData.txt');\r\nreader2 = reader1;\r\n%%\r\n% But this time, rather than call the destructor explicitly, I will just\r\n% clear one of the handles.  As we saw earlier, this can result in an implicit\r\n% call to the |delete| method:\r\n\r\n%%\r\nclear reader1;\r\nisvalid(reader2)\r\n%%\r\n% Why is |reader2| still valid, and why was my destructor not called?\r\n% Because MATLAB will only implicitly call a destructor when the *last*\r\n% reference to an object is cleared.  As |reader2| still exists in my\r\n% workspace, the underlying |FileReader| is not destroyed.\r\n%\r\n% Most often a destructor is defined as a public method, but it can also be\r\n% declared as a private or protected method.  Making it private will \r\n% prevent code outside the class from explicitly calling the destructor. \r\n% Similarly, a protected destructor can only be explictly called\r\n% from methods of the same class or from subclass methods.  MATLAB\r\n% will always be able to implicitly call a destructor, even one declared\r\n% private or protected.  You might choose to restrict access to your\r\n% destructor in a situation where you want to prevent the accidental\r\n% deletion of an object, such as when you have a singleton object.\r\n\r\n%% Handles Contained within Other Structures\r\n% What happens when a handle is stored as a field of a struct or a cell of\r\n% a cell array, or as a property of another object?  When that top-level\r\n% container variable is destroyed, the handle object will also be\r\n% destroyed and its |delete| method implicitly called if and only if no other\r\n% references to the object exist.  Let's look at an example with structs:\r\n\r\n%%\r\ns.myReader = FileReader3('colorData.txt');\r\nclear s\r\n%%\r\n% Note that the |FileReader| stored in the |myReader| field of |s|\r\n% has been destroyed.  However, as we saw previously, another handle to the\r\n% same |FileReader| will prevent the destruction of the object:\r\n\r\n%%\r\nreader4 = FileReader3('colorData.txt');\r\ns.myReader = reader4;\r\nclear s\r\nisvalid(reader4)\r\n%%\r\n% Even after clearing |s|, we see that |reader4| is still valid.  The \r\n% second handle prevented the implicit destruction of the object.\r\n\r\n%% Classes in Hierarchies\r\n% So far we have been looking at examples of stand-alone classes, but what\r\n% about classes that are part of a hierarchy?  In MATLAB, every class has \r\n% the ability to control its own destruction behavior.  In a \r\n% hierarchy of classes, every class can define its own destructor.  As a\r\n% result, a destructor cannot be defined as a |Sealed| method. \r\n%\r\n% When an object is destroyed, MATLAB will call the destructor of the\r\n% class of the object first, if it has been defined.  Next, the destructor\r\n% of each superclass is called, starting with the most direct superclass.\r\n%\r\n% A destructor can reference the properties of the class itself, including\r\n% properties inherited from superclasses, but it generally should not reference \r\n% properties of a subclass.  Why?  Because when a superclass destructor is executing,\r\n% the destructor of its subclass has already executed, and could have\r\n% invalidated the values in its properties.\r\n\r\n%% How Do You Use Destructors?\r\n% Now that we've discussed the basics of working with\r\n% destructor methods in MATLAB, I'd like to hear of your experiences.\r\n% Are you already using destructors?  If you have any interesting\r\n% applications or questions, I'd be very happy to hear about them\r\n% <https:\/\/blogs.mathworks.com\/loren\/?p=748#respond here>.\r\n\r\n \r\n##### SOURCE END ##### e4457c9de1124805ad16ce155c11c77c\r\n-->","protected":false},"excerpt":{"rendered":"<!--introduction--><p>I'm pleased to introduce guest blogger Jennifer Black, manager of the MATLAB object system team.  Today Jennifer will be sharing some thoughts on what happens when objects are destroyed in MATLAB and how you can control aspects of this process.... <a class=\"read-more\" href=\"https:\/\/blogs.mathworks.com\/loren\/2013\/07\/23\/deconstructing-destructors\/\">read more >><\/a><\/p>","protected":false},"author":39,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[44],"tags":[],"_links":{"self":[{"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/posts\/748"}],"collection":[{"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/comments?post=748"}],"version-history":[{"count":9,"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/posts\/748\/revisions"}],"predecessor-version":[{"id":2260,"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/posts\/748\/revisions\/2260"}],"wp:attachment":[{"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/media?parent=748"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/categories?post=748"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/loren\/wp-json\/wp\/v2\/tags?post=748"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}