Infinite Recursive Property Assignment

I am writing code to process all of the variables in the workspace to see which ones are shared with each other. Suppose I define a simple classdef as follows:

classdef theclass
    properties
        a
        b
    end
end

Then I do the following:

>> x = theclass
x = 
  theclass

    Properties:
      a: []
      b: []
    Methods
  >> x.a = 1:3
  x = 
    theclass

    Properties:
      a: [1 2 3]
      b: []
    Methods
  >> x.b = x
  x = 
    theclass

    Properties:
      a: [1 2 3]
      b: [1x1 theclass]
    Methods
  >> x.b
  ans = 
    theclass

    Properties:
      a: [1 2 3]
      b: []
    Methods
  >>

Everything is fine so far. The state of x prior to the x.b = x has [] in the b property, and it is that state of x that is used to assign into the b property. All well and good. The variables I can find in the workspace are x, x.a, x.b, x.b.a, and x.b.b

But now define a new classdef that derives from handle:

classdef theclasshandle < handle
    properties
        a
        b
    end
end

And do the same operations:

>> x = theclasshandle
x = 
  theclasshandle handle

    Properties:
      a: []
      b: []
    Methods, Events, Superclasses
  >> x.a = 1:3
  x = 
    theclasshandle handle

    Properties:
      a: [1 2 3]
      b: []
    Methods, Events, Superclasses
  >> x.b = x
  x = 
    theclasshandle handle

    Properties:
      a: [1 2 3]
      b: [1x1 theclasshandle]
    Methods, Events, Superclasses
  >> x.b
  ans = 
    theclasshandle handle

    Properties:
      a: [1 2 3]
      b: [1x1 theclasshandle]
    Methods, Events, Superclasses
  >> x.b.b
  ans = 
    theclasshandle handle

    Properties:
      a: [1 2 3]
      b: [1x1 theclasshandle]
    Methods, Events, Superclasses
  >> x.b.b.b.b.b.b.b.b.b.b.b.b.b.b.b.b.b.b.b.b
  ans = 
    theclasshandle handle

    Properties:
      a: [1 2 3]
      b: [1x1 theclasshandle]
    Methods, Events, Superclasses
  >>

Well, now you see the issue. The b property points back to the original variable, creating an infinite recursion. You can stack up as many .b properties as you want and MATLAB will happily do the operation.

This creates a problem if I am programmatically trying to create a list of every variable, cell element, struct field, and class variable property in the workspace ... the list will be infinite.

Has anyone had to deal with this type of situation? How can I detect that there is an infinite recursion going on? I.e., if I programmatically process an object by recursively processing all of its properties, how can I detect that there will be an infinite loop going on with this recursion?

Answer 1

[Guillaume]

I'm not sure what you mean by the old @directory class objects. This looks like just a handle issue to me.

You will also encounter problems if object handle A reference object handle B which itself references object handle A (e.g. doubly linked list, or parent/child relationships) as this creates circular references.

The only way I can see you breaking out of these would be to keep a list of the variables/fields/properties that are handle objects and if encounter them again, not process them again:

handlelist = {};
%...

%... assuming currentvar is scalar. More complex code needed to handle object arrays
if isobject(currentvar) && isa(currentvar, 'handle')
   if any(cellfun(@(obj) currentvar == obj, handlelist))
      %already seen that handle, don't process it again
      continue;
   else
      handlelist = [handlelist, {currentvar}];
      %process object
   end
end
%...

[James Tursa]

"... the old @directory class objects ..."

I deleted that part from my post, so it no longer applies.

What you propose looks somewhat similar to how I am currently doing this (trying to keep track of what classes I have already processed for a particular variable and stopping if I encounter the same class again). I will have to consider this in more detail ... (particularly since whatever I do will need to go into a mex routine).

[James Tursa]

I have incorporated the isa(___,'handle') into the mex routine. An excellent suggestion that appears to get the job done well enough for my purposes. Thanks.

Answer 2

[Walter Roberson]

This is pretty much the same problem as is encountered in Garbage Collection.

See https://en.wikipedia.org/wiki/Tracing_garbage_collection

containers.Map with keys that are the addresses of the data structures might be useful, by the way.