How to execute a function when stored in a variable

I am trying to find a way to store instructions on executing a line of code in a variable, so that when a user loads in that variable, they can execute the line of code contained within the variable. A simple example of something I'd like to run is:

sprintf('example %s',localVariable)

So the user's code would look something like:

localVariable = 'foo';
loadedVar = load('file.mat','Var'); %where 'Var' is something along the lines of @eval('sprintf(''example %s'',localVariable)'), but I can't seem to figure out exactly how to do this
a = loadedVar %I think I want loadedVar to be a function handle of some sort, where the function looks at the local workspace for 'localVariable' and constructs a string;

The desired output then when calling 'a' is:

'example foo'

Any ideas on how to accomplish this?

Answer 1

[Jan]

This is the job of functions. Hiding the function as char vector in a MAT file is too strange to be clear or efficient. Simple store the funtion in an M file and call it.

Do not reinvent Matlab as a programming language based on interpreting the contents of MAT files.

[Dan Klisiewicz]

Thanks, could you be a little more explicit on what function to store in a .m? In my example, are you referring to:

sprintf('example %s',localVariable)

To give you some context as to why I'm trying to do this - the codebase I'm working with has a large amount of references to a path stored inside of a configuration file. A recent update requires that this path be more dynamic (e.g. what used to just be 'C:/path/to/data' can now be 'C:/path/to/typeA/data' 'C:/path/to/typeB/data', and so on). I understand that I can manipulate this in each piece of code that references this variable, but this would be enormousy tedious! So I was looking for a way that I could configure the variable in the config to be more dynamic.

[Stephen23]

" understand that I can manipulate this in each piece of code that references this variable..."

Passing the required data as input/output arguments would be the best solution.

"...but this would be enormousy tedious!"

It is not "tedious" to pass input/output arguments reliably (in fact it lets you concentrate on more important things).

In contrast the approach you have chosen obfuscates the code intent, and forces you into writing complex, inefficient, slow code which is liable to bugs and difficult to debug. That is a very... interesting design decision.

https://xyproblem.info

https://en.wikipedia.org/wiki/XY_problem

[Dan Klisiewicz]

A couple of notes:

Thanks for your suggestion and elaborating on input/output argument solution. It is most likely the solution I will move forward with.

Why would you comment on how tedious a task would be if you haven't seen the breadth of the code I'm dealing with?

You are correct, the approach in question is complex and most likely ineffecient - but these are some things you have to consider when weighing how long it would take to implement a simpler, more efficient solution vs. the need for a particular task to be completed and the level of risk adding such complexity would add. There's nothing wrong with exploring different solutions. That being said, this is not a case of the XY problem as the end user knows exactly what could be done to fix X.

"The inability of the support personnel to resolve their real problem or to understand the nature of their inquiry may cause the end user to become frustrated. The situation can make itself clear if the end user asks about some seemingly inane detail which is disconnected from any useful end goal. The solution for the support personnel is to ask probing questions as to why the information is needed, in order to identify the root problem and redirect the end user away from an unproductive path of inquiry. "

The support person WAS able to offer support to resolve the real problem and the support person did not have to ask probing questions as to why the information was needed. You'll notice that in my response I didn't say "how do I achieve not touching every piece of code that comes in contact with this variable". This is because I knew very well ahead of time what could be done to resolve X. Y came along as an alternate (borderline inane) solution that came about in my explorations that led me to try to understand Matlab's mechanisms better.

I appreciate Jan's suggestion and only replied because I needed clarification on one of his statements. I offered some context to show that I've thought about my approach in different ways. There was no frustration until you accused me of offering an unproductive path of inquiry.

Please stick to constructive comments such as "Passing the required data as input/output arguments would be the best solution." and leave it at that.

Answer 2

[Asmit Singh]

I hope eval, feval documentaion migh come handy. Did not exactly get the question.

[Dan Klisiewicz]

In my description I mention trying to use eval, but not being able to quite figure out the syntax, hence why I asked the question. This type of comment is not helpful at all.