Thread Subject: How to summarize Matlab's OOP features?

Hi,

I have been looking at OOP facilities of Matlab, and wrote
up an ultra- brief bullet-point summary, to jog my memory
if/when I get around to using them. Would anyone counsel
corrections or additions?

Thank you.



a) 'dedicated' class folder

b) absence of a header/prototype file listing class members
(constructor lists only class properties, not other methods)

c) classes as property-containing structures, converted
with 'class()'

d) 'segregation' of class methods into separate m-files

e) optional 'display' and 'char' methods

f) any derived-class object contains the 'enveloped' base-
class object as its explicit member

g) an (at-least-) two-step way of modifying an object by
its method: a property change, then an "eval('base',.."-
like "assignin('caller',.." 'commit'

h) class properties: always private

i) class methods: public, unless respective m-files are
placed in 'private' sub-directory

j) inheritance: always private (hence, methods of a derived
class can access inherited base-class properties of a
derived-class object only through base-class accessors)

k) no derived-to-base casts

l) no pure virtual methods (hence, no abstract classes)

m) [See (f)] a two-step way of invoking a virtual base-
class method (vs. the derived-class 'override' namesake).
For example, to get the balance of a savings account, with
SavingsAccount derived from BankAccount and getBalance
implemented in BankAccount, need:

parent = sa.BankAccount;
ans = getBalance(parent);

n) [Combination of (g) and (m)]. a four-step (!) way of
modifying inherited properties of a derived-class object.
For the example above, with balance a property of
BankAccount class, adjustable through its setBalance
method, need

parent = sa.BankAccount;
setBalance(parent,100)
sa.BankAccount = parent;
assignin('caller',inputname(1),sa)

Going back to (g), if balance belonged to SavingsAccount,
two steps would suffice:

sa.balance = 100;
assignin('caller',inputname(1),sa)

o) no static classes

.. I think I would stick another bullet point between (d)
and (e):

'Within m-file' overloading: for example, default
constructor, 'regular' constructor and copy constructor are
placed in a single m-file, and choice between the three
made by testing inputs