Thanks!

The initialization code in my GUI follows the following sequence:

c = CreateConstants(); % Returns a structure, c, of ‘constants’
h = CreateGuiObjects(c); % Returns a structure, h, of handles to GUI objects.
AssignGuiCallbacks(h,c); % Assigns callbacks to objects

As long as the assignments made in AssignGuiCallbacks use anonymous function calls, the argument c is fixed at the time the assignment is made (refer to Matlab help on the topic). An example of an assignment might be:

set(h.tmrMain,’TimerFcn’,{@tmrMain_TimerFcn,h,c});

Whenever the TimerFcn event is subsequently triggered, tmrMain_TimerFcn will always use the value of c that was defined at the time the anonymous function call was defined.

I have found this technique to be very useful in this application as all functions are callbacks, or called as a sub-routine from a function that is a callback.

This method is still not bulletproof; there is nothing to prevent one from changing c from withing a function, although changes will not persist between calls.

I also find that using a structure such as this mitigates the risk of changes as a) it is obvious that anything that is part of the structure is not meant to be changed and b) a short name like ‘c’ reserves plenty of room for descriptive field names. I prefer to name globals in ALL CAPS in order to make the distinction between the two variable types.

Having said all this, I _would_ like the ability to define true constants in Matlab. My concern about the ‘function’ method outlined by Loren above, is the potential performance hit encountered if many constants are used in time-sensitive calculations. Is this a reasonable concern?

Gene

% Constants – call f’n here to prevent overwriting
PLANCK;
PI_OVER_TWO;

The problem is, this seems to be a very clunky way to provide constant-like functionality without having to add them to the Matlab scripting language. Why not just figure out how to support constants, and then support them?

It is an iteresting script that allows you to define constants What it does is automatically create functions like the technique suggested by Loren such that you get an error if you try to use a variable of the same name.

I’ve only briefly looked at the code so cannot comment to its limitations but it looks useful.

Once again, this does not prevent overwriting as does the function definition technique. I agree and wish you could define constants and “lock” them.

The overhead is less if all the constants were is a structure (i.e. Constant.PI, Constant.TWOPI), but that makes the code a little gross.

I would be much happier (and swear a little less at Matlab) if you could define constants like in C, that would be handled before runtime.

I like simple solutions.
I’d like to see a keyword, mconstant, for example, that
allow the folowing construct:

mconstant TWO__PI +6.28;

—

a) restrict the data type (and array shape/size?) on function arguments. Testing with IS*, NDIMS and SIZE sometimes becomes very tedious.

b) specify that a function argument is intended to be CONST. A syntax like

function fun( const a )

would be useful.

c) override the copy-on-write-semantics, meaning that I want to modify the value of the argument itself, not a copy. If I want to have a function which changes a certain variable, currently I have to do convolutions such as
a = fun(a)
which, is bound to be inefficient. However, I don’t think it would be a good idea to introduce “real” reference parameters (such as C/c++ do), as this would change the semantics of Matlab programs too much. Perhaps a syntax could be devised to force the user to use the same name for input and output and then give Matlab a cue to handle the argument as a reference and not apply copy-on-write. A syntax like this might do it:

function [a,b,c] = fun( ref a, b, c )

where only “a” would be protected from copy-on-write.