Bobby Nedelkovski

Thank you for your feedback and suggestions Joao.
 
I appreciate you pointing out the bug with the add() method in class CellArrayList. The bug (infinite while-loop) occurs when capacity = numElts and remove() is called numElts consecutive times to reduce capacity to 0. Subsequently, if you call add(), the while-loop used to re-allocate memory for the list cell array container won’t exit!
 
I have since fixed this issue and have submitted an update which will be published on the File Exchange soon.
 
Your suggestions of overloading critical MATLAB system methods such as ‘subsref’ and ‘subsasgn’ for the short-term benefits of element/property replacement is dangerous. Experienced MATLAB programmers will know that natural index notation is used to index into arrays of data types e.g. array of structs or array of cell arrays or array of char arrays or in this case, array of CellArrayLists!
 
Incidentally, I have just uncovered another bug with reference to how I’ve implemented all my methods with respect to the creation of arrays of CellArrayLists – i.e. myList = CellArrayList(); myList(2) = CellArrayList(); – and the way in which I’ve overloaded system methods ‘isempty’, ‘length’ and ‘display’!
 
This just goes to show that you need to be extremely cautious when deciding to overload MATLAB system methods! However, I like the idea of having a specialised ‘replace’ method which will effectively execute the ‘remove’ method followed by the ‘add’ method. In this way, you can easily replace elements in the list yet according to OOP practice, it is still perfectly acceptable for programmers to retrieve ADT elements and simply modify properties (this is all you need to do for objects of reference behaviour) and insert them back into the list (for objects of copy behaviour).
 
Joao, please feel free to contribute to the development of the ‘replace’ method. I can review your code if you send it to me by email which you can find off my File Exchange profile page (just click on the hyperlink ‘Bobby Nedelkovski’ on this page).

Thank you for your feedback Kun-Chul.

To provide clarification to the comment "good implementation for the oo design principle: polymorphism!!":

The CellArrayList implementation of the List ADT provides 'polymorphism' at the element level as I've indicated in File Exchange item #25024 by stating that CellArrayList is a storage container for a *heterogeneous* set of elements.

On the other hand, polymorphism at the list object creation level can't be generally enforced since MATLAB is loosly typed. Ideally, to conform with good software engineering practice, it would be beneficial to declare an identifier using an interface/abstract class so you just need to change the instantiating class if you simply want to switch from one implementation of List to another (i.e. you cannot perform "List myList = CellArrayList();" so then you would simply need to modify this line to use another implementation "List myList = AnotherImplList();"). So in this case, polymorphism is not apparent in MATLAB OOP.

On the alternative implementation of method 'locationsOf' (i.e. "locs = find(cellfun('isclass',obj.list,class(elt)));"), I have asserted in the comments for 'locationsOf' in abstract class 'List.m' that it should return the locations of all occurances of a single element in the list; speed shouldn't be necessarily the issue here. Hence why I use a strict equality test in "locs = find(cellfun(@(c)isequal(c,elt),obj.list));" *not* simply checking the element type. For example, if I define a list of the sort "x = [1,2,{3,4;5,6},{7,8;9,10},11]" and test x.locationsOf(2), the 'isequal' implementations yields the correct result of 2. The 'isclass' implementation will yield the relative locations of elements 1,2 and 11 given their data type matches the data type of the input argument. This is then contrary to the "contractual agreement" defined in the comments for 'locationsOf' in the abstract class 'List.m'. Sure, though you are welcome to have specialised methods in your custom subclasses of the List ADT - for example, perhaps an 'isclass' operation could be be encapsulated in a method called 'classTypeLocationsOf'.

Finally, to comment on "I hope Mathworks to develop cell array vectorization for matlab oop...", the idea of this CellArrayList realisation of the List ADT and OOP in general is to hide the low-level detail in implementation of certain functionality (like performing "find(cellarray..." or even for that matter "find(listObj==obj)" as suggested) since the user of CellArrayList only needs to know how to use 'locationsOf'. So the onus is on the developer to create their own implementations of specific class methods using base MATLAB functionality; therefore OOP shouldn't be seen as a replacement for or thought of as superseding base MATLAB functionality since functions like 'cellfun' still have their place.

Thank you Bobby! for your excellent implementation of this classic design pattern. I especially appreciate your extensive documentation & excellent, highly-descriptive coding style.
5-stars well-deserved. If only all MATLAB code could look like this! Highly recommended.

test

classdef A < handle
  properties
    b = containers.Map
  end
end

please note that containers.Map is itself a handle class, which is not covered in the copyobj function from Volkmar Glauche. You could recursively call copyobj for handle properties, but then you're facing the next problem of private properties (Maps has private props), which cannot be copied as already mentioned.

In order to copy this class, the "ugly" solution from Barry Ridge is unfortunately the only thing which works in order to deep copy an instance of class A.

any news on this issue from Mathworks?

best regards
kusi