Although slightly different from the usual approach, this will have almost all of the same disadvantages as the usualdynamic variable names that some beginners like to use to force themselves into writing slow, complex, buggy code:
This is very true. Often, one can find a cleaner solution without dynamic types, variable names and so on.
Thank you for your comment. I had a slightly tricky problem involving construction of nested objects, and I realized that it would be easier to let the user call the constructor using a list of empty objects rather than a list of strings.
Aah, I didn't know that (or at least didn't think of it, given that I've probably used that "feature" implicitly many times) - resulting in another time-consuming circular walk in woods. Thanks.
Doing this - making variables named from strings - is a bad idea. I mean, just how would you refer to that variable later? How would you use it if you don't know the variable name before run-time? Seethis link
It's extremely easy to come up with a piece of text that is not a valid class name but if used with Image Analyst's suggestion would do various nasty things. I'm not going to post one because I don't want people to get angry if they closed their MATLAB session by running the example.
OK, so it turns out, that I cannot do what I wanted to accomplish. The original problem arose from my not wanting to write an extra (ugly) four lines of code.
Suppose I have a container class:
class Container
properties
elements;
end
methods
function This = Container()
end
function This = push(This, obj)
This.elements(end+1) = obj;
end
end
end
Those familiar with Matlab will know that this will not work, as Matlab initializes "elements" to an empty "double" type and I cannot push another object into that array. Of course the problem is easily solved by rewriting push as:
This = push(This, obj)
if isempty(This.elements)
This.elements = obj;
else
This.elements(end+1) = obj;
end
end
But this grated on the senses, so I thought, why not indicate the type of "elements", in the constructor, like:
function This = Container(empty_array_of_desired_type)
This.elements = empty_array_of_desired_type;
end
Which is a nice solution allowing me to write the push method cleanly. The problem arises when "element" objects can also be containers (of a different type in the same hierarchy) and the elements of "elements" can also be containers - in other words there could be a certain amount of nesting. There is no way to provide all the right empty types to all levels without using eval() to dynamically create empty arrays of the right type, and even then it gets ugly with all the checking.
Conclusion: Bite the bullet and tolerate a little ugliness in the push method.
You can also select a web site from the following list:
How to Get Best Site Performance
Select the China site (in Chinese or English) for best site performance. Other MathWorks country
sites are not optimized for visits from your location.