Is it more efficient to pass data between functions by global variables than handles structure in Matlab GUI?
Thanks,
Myrick
Just to complement Pariah's and Lucius' answers, if you intend to deploy your GUI as a standalone application you will likely discover that it's a bad idea to use global/persistent variables.
There are of course some workarounds you can use but as Pariah mentioned, it's good practice to limit your use of global variables although they highly simplify code development.
Depends mainly on what you want to do.
I mean normally i do global variables for prototyping, (and it is poor practice to set all variables to global for security and for performance reasons).
But then again when passing variables via handlers, is a good practice that you really should get into because it not only gives you a better insight into the data you are passing but forces you into good coding practices to aid in debugging and future work that you may extend on your current work.
(This is more of a suggestion but also if you set global variables it can create nightmares when debugging code).
depending on how big is your data, you could see differences in terms of speed.
the main reason is (correct me, if I'm wrong):
the handles-struct is always a copy (call-by-value)->big data->low speed; in addition, one has to re-assign changes; global variables are called by reference
but of course, maintaining a code with many global variables can get more complicated. If someone got the time: create a simple performance-test, that compares both variants with different sizes of data passed :)
Related
I am working with a legacy scala codebase, and as is always the case modifying the code is quite difficult without touching different parts.
One of my new requirement in to make several decisions based on some input parameters. Problem is that these decisions are to be made at various points along the execution. So either I encapsulate all those parameters in a case class instance and pass it along. But it means I would have to modify multiple methods signatures, and I want to avoid this approach as much as possible.
Another approach can be to create a global object containing all those input parameters and accessible from different points in the execution. Is it a good approach in Scala?
No, using global mutable variables to pass “hidden” parameters is not a good idea, not in Scala and not in any other programming language. It makes the code hard to understand and modify, because a function's behaviour will now depend on which functions were invoked earlier. And it's extremely fragile, because you might forget setting one of those global parameters before invoking the function, which means that it will use whatever value was stored there before. This is the kind of thing that can appear to work for years, and then break when you modify a completely unrelated part of the program.
I can't stress this enough: do not use global mutable variables, period. The solution is to man up and change those method signatures. Depending on the details, dependency injection may or may not help in your particular case.
I want to write a modular matlab program and I have some data structures such as history in my program. Is that true that I have to keep all my data-structures in the main script of my program? In other words if I have some arrays and fields of data, if I put them in other m files, such as functions, they are temporal and they are going to be collected as garbage in my program execution. I am a java developer and now I want to develop some code in matlab.
As Tommaso suggested in a comment, you should use classes. Look at the documentation for classdef to get started. The full documentation to create classes starts at this page.
But to directly answer your question: it is possible to store static data in functions: see persistent.
If you're making a GUI, there are built-in ways to store data, see guidata.
Finally, there is also getappdata and setappdata, which set global variables but specific to one app.
For all that's good in this world, don't use global, it's not worth the hassle, here are plenty of better alternatives.
PS: if the links here break, note that it is always possible to type help <cmd> to get help on one of the functions mentioned here.
According to best practices (for instance, http://www.sencha.com/blog/top-10-ext-js-development-practices-to-avoid), I should avoid using global variables and instead create them as configs of a static class, ApplicationName.foldername.Classname.
Hence, a call to a tiny variable varName would become a verbose ApplicationName.foldername.Classname.getVarName().
Is is possible to shorten the ApplicationName.foldername.Classname part, in any way?
It's all just JavaScript - so technically ApplicationName.foldername.Classname is a global variable, albeit one that is unlikely to create naming collisions in this use case.
In other words, the likelihood that something short like varName is used more than once in a large application is pretty high... which is why it's bad practice. Creating something shorter, while certainly more convenient (less typing), is riskier.
In my iPhone development, I've always used global variables for lots of stuff. The style guide in my new job says we should use context parameters instead. So I need to figure out what that means and how to do that.
Can anyone explain in more detail what this means -- or point me to some code that works this way?
Thanks
It sounds like there may be a clash in nomenclature. From this definition of Context Parameters, they seem to be concerned storing global state for the duration of a session. Perhaps, you could use a 'contextParameters' NSDictionary within NSUserDefaults to store your globals. To the extent that your globals might need to be exported in their entirety (for debugging, for state saving) this might be useful in the long run.
The style guide might just be generically saying to keep your variables scoped based on the context of their usage. For example if you have a variable that you need for the lifetime of a class instance then make it a member variable of that class. If it is something that you need for the lifetime of the app then put it in an application wide object (but not a global variable).
If you use a global object (which could mostly be a big C struct containing all your former global variables) instead of individual naked global variables, you might be able to copy the object, serialize it to save it or create a unified core dump, eventually add setters/listeners, etc.
If you break the global object up, based on the shared scope or the required context of groupings of instance/struct variables, then the fractional objects might end up being good candidates for the M portion of an MVC repartitioning of your code for better reuse, extensibility, etc.
I think I understand why there is a danger in allowing closures in a language using dynamic scope. That is, it seems you will be able to close the variable OK, but when trying to read it you will only get the value at the top of global stack. This might be dangerous if other functions use same name in the interim.
Have I missed some other subtlety?
I realize I'm years late answering this, but I just ran across this question while doing a web search and I wanted to correct some misinformation that is posted here.
"Closure" just means a callable object that contains both code and an environment that provides bindings for free variables within that code. That environment is usually a lexical environment, but there is no technical reason why it can't be a dynamic environment.
The trick is to close the code over the environment and not the particular values. This is what Lisp 1.5 did, and also what MACLisp did for "downward funargs."
You can see how Lisp 1.5 did this by reading the Lisp 1.5 manual at http://www.softwarepreservation.org/projects/LISP/book
Pay particular attention in Appendix B to how eval handles FUNCTION and how apply handles FUNARG.
You can get the basic flavor of programming using dynamic closures from http://c2.com/cgi/wiki?DynamicClosure
You can get an in depth introduction to the implementation issues from ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-199.pdf
Modern dynamically scoped languages generally use shallow binding, where the current value of each variable is kept in one global location, and function calls save old values away on the stack. One way of implementing dynamic closures with shallow binding is described at http://www.pipeline.com/~hbaker1/ShallowBinding.html
Yes, that's the basic problem. The term "closure" is short for "lexical closure", though, which by definition captures its lexical scope. I'd call the things in a dynamically scoped language something else, like LAMBDA. Lambdas are perfectly safe in a dynamically scoped language as long as you don't try to return them.
(For an interesting thought experiment, compare the problem of returning a dynamically scoped lambda in Emacs Lisp to the problem of returning a reference to a stack-allocated variable in C, and how both are impossible in Scheme.)
A long time ago, back when languages with dynamic scope were much less rare than today, this was known as the funargs problem. The problem you mention is the upward funargs problem.