Here is some sample code:
x = 0 ;
myClass.x = val ;
Then I can run:
>> myClass.x = 1 ;
ans = 1
So far, so good, but then
>> myClass.f(2) ;
ans = 1
What the heck?
What is a static property? Is it just the opposite of a dynamic
property, in other words, a normal property?
In any case, your function myClass.f doesn't have access to your
object's properties because you have defined it to be Static. All your
function does is implicitly define a new structure called myClass and
assign val to the x field. Then it doesn't return anything. Finally,
the way you have tried to use f() you'll need myClass to be a handle
I think what you want is:
--------------- myClass.m ---------------------
classdef myClass < handle
x = 0;
this.x = val;
Also, in your use of this class you have mixed up the class name and an
instance of the class. The code should look something like this:
>> a = myClass;
>> a.x = 1;
Is that the kind of thing you're trying to do? I still don't know what
adding the attribute Static to the properties will do since, as you say,
it is undocumented.
Make obvious changes to get real email address.
In OO programming, a static property is analogous to a static member
function. It is defined on the class instead of class instances.
That is why this code that I originally posted works:
>> myClass.x = 1 ;
ans = 1
I can set the property using the class name (first line) and access it
using the class name (second line), no instance required. This is
extremely useful, just as static member functions are extremely
useful. I would expect static member functions to be able to access
and modify static member data, as with most (all?) OO languages.
Okay, I understand now, thanks. Given what you say and the fact that
you seem to be able to do it from the command line, I'd agree that your
static method should be able to set the static class property. I will
play with this myself and if I discover something useful I'll post again.
Maybe there's a reason that static properties are not documented. :-)
I have had a chance to try out your code, but my results are not quite
the same as yours:
>> clear classes
>> myClass.x = 1;
??? Reference to non-existent field 'f'.
>> clear classes
I can access the x property of myClass, but when I try to run the f
method I find that myClass has been assigned as a structure. After
clearing everything again I am able to run f, but it behaves as you saw
and after inserting a disp(class(myClass)) statement in the f method I
see that, once again, myClass has become a struct in that workspace.
So, it seems that you cannot change the value of x in the class at all.
In fact, I don't see how it could work and remain consistent with MATLAB
syntax. At the moment when I execute myClass.x = 1, the workspace is
empty so MATLAB creates the myClass structure. It could work no other
way otherwise if someone tried to create a structure that happened to
have the same name as an existing class there would be a conflict.
Perhaps that's why static properties are undocumented.
> It could work no other way otherwise if someone tried to create a structure that happened to have the same name as an existing class there would be a conflict.
This is already a problem with static member functions (as your
previous post shows), so really would be no different with static
properties. I guess I just need to accept that the implementation is
incomplete for now. It is clearly partially implemented, as I can use
the Static attribute with the properties keyword without getting an
error. And with the Static keyword, I can do a get (myClass.x), just
not a set (myClass.x = 1). Also, if I remove the Static keyword, I
can do this:
??? No Static property 'x' in class 'myClass'.
So MATLAB clearly knows what I am trying to do.
If anyone knows of a way to fake this out, please let me know.
Constant properties may not be changed from the initial value specified in
the property declaration. There are a couple of reasons why MATLAB works
the way it does. First, MATLAB has longstanding rules that variables always
take precedent over the names of functions and classes and that assignment
statements introduce a variable if one doesn't already exist. Thus, any
expression of the form "A.B = C" will introduce a new variable A that is a
struct array containing a field B whose value is C. If "A.B = C" could
refer to a static property of class A, then class A would take precedent
over variable A and this would be a very significant incompatibility with
prior releases of MATLAB. It would mean that an m-file containing the
assignment statement "A.B = C" could have its meaning changed by the
introduction of a class named A somewhere on the MATLAB path. MATLAB
programmers have always been able to rely on assignment statements
introducing variables that shadow any other use of the same name.
Second, we have observed that static data is rarely used in other classes
except as private data within the class or as public constants. For
example, a survey of several Java class libraries found that all public
static fields were also final. In MATLAB, Constant properties can be used
like "public final static" fields in Java. For data internal to a class,
MATLAB already has persistent variables that can be created inside of
private or protected methods or local functions privately used by a class.
There are also good reasons to avoid static data in MATLAB where possible.
If a class has static data, it can be difficult to use the same class in
multiple applications because the static data can be a source of conflicts
among applications. In some other languages, this is less of an issue
because different applications are separately compiled into executables
running in different processes with different copies of class static data.
In MATLAB, frequently many different applications may be running in the same
process and environment with a single copy of each class.
"navels" <nav...@gmail.com> wrote in message
Excellent, thanks for all the background info!
This thread looks fairly stale, but it was the one that came up while I was searching, so I thought I would add my comment in the hope it will help others in the future.
I was also expecting to be able to have static properties, and had to find a work-around for what I was doing.
Here's a couple of things that I found one could do to get around this limitation.
As one option, the initial values don't have to be literals - you can call a function. See the "assigning values to constant properties" in the docs here: http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_oop/br4is5o-1.html
They use this example:
RN = rand(5);
Unfortunately, this appears to only work with matlab intrinsic functions. In other words, I was unable to write my own function to do what I needed (not even a static one). Also, you can't change the value of RN at runtime.
In my case, the data member that I wanted to share across object instances was "kind of" "final". I didn't need to change the values at runtime, but I wanted all object instances to share a block of data. It was only created once, but that creation was computationally expensive, and the result was large. In other ways, the object is naturally a "value" object, but creating a copy of this "static" property for every instance was wasteful.
So here's the solution I used. I created a handle object that contained only the static property, then had a property in the main value object that contained a reference to the handle property. This way the static property could be shared (as a handle to an object) across instances, and only the handle was stored in the instances.
Note that this is, in effect, the Singleton pattern nicely shown here: http://www.mathworks.com.au/matlabcentral/fileexchange/24911
And reading the docs at the top of Simpleton.m, you see that they had to use the "persistent" keyword to work around the fact that "MATLAB OOP doesn't have the notion of static properties."
Anyway, here's the general mock up of what I did:
classdef HandleClassWithProperty < handle
This way I could create a single staticProperty (that was expensive to create and large) that was shared among instances of my value class.
After doing it this way, I realized that implementing it as a Singleton was actually a more elegant solution (in my situation) than a static property.
Hope this helps someone out there!