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.
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.
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 :)
Would like to get some thoughts on how to best organize session vars within a scala / lift application.
I've read over a number of scala materials online and have found generally the following paradigm in all examples that introduce session vars:
declare an object that extends the SessionVar class
put that object into a file that contains a snippet (or any file)
access that object from anywhere in the codebase (lift will take care of the session var's lifecycle based on the lifetime of the user's http session)
Perhaps I'm not understanding something, but I'm concerned that this approach would lead to a whole bunch of these objects in various files all over the place. Its not such a big deal if its a small app, but when a project gets larger this could lead to chaos.
For those who have worked on larger scala projects, is there a generally accepted better approach? (even if its something simple like putting all of these objects into a common file?)
Thanks.
This is a bit subjective, but I'll give it a try. I think it depends on the scope the session var has in your project.
If you need the session var only in one snippet, you should make it a private member of that class.
If you need it in several but not all snippets, put those snippets in a package and make the object private to that package. If you have a lot of them, you could create an extra file to hold them.
If you need it globally, put it into a central location, maybe inside a package object.
If possible, avoid using SessionVars completely.
SessionVars should be used sparingly in your application. They are similar to Servlet Session Variables, except they are type safe.
How many session variables do you need? Personally, I have a session variable for the primary key of the current user and maybe one or two more. The rest of the state of the application should be stored in closures (because functions associated with GUIDs close over scope).
I have a variable that I need to pass to a subroutine. It is very possible that the subroutine will not need this variable, and providing the value for the variable is expensive. Is it possible to create a "lazy-loading" object that will only be evaluated if it is actually being used? I cannot change the subroutine itself, so it must still look like a normal Perl scalar to the caller.
You'll want to look at Data::Lazy and Scalar::Defer. Update: There's also Data::Thunk and Scalar::Lazy.
I haven't tried any of these myself, but I'm not sure they work properly for an object. For that, you might try a Moose class that keeps the real object in a lazy attribute which handles all the methods that object provides. (This wouldn't work if the subroutine does an isa check, though, unless it calls isa as a method, in which case you can override it in your class.)
Data::Thunk is the most transparent and robust way of doing this that i'm aware of.
However, I'm not a big fan of it, or any other similar modules or techniques that try to hide themself from the user. I prefer something more explicit, like having the code using the value that's hard to compute simply call a function to retrieve it. That way you don't need to precompute your value, your intent is more clearly visible, and you can also have various options to avoid re-computing the value, like lexical closures, perl's state variables, or modules like Memoize.
You might look into tying.
I would suggest stepping back and rethinking how you are structuring your program. Instead of passing a variable to a method that it might not need, make that value available in some other way, such as another method call, that can be called as needed (and not when it isn't).
In Moose, data like this is ideally stored in attributes. You can make attributes lazily built, so they are not calculated until they are first needed, but after that the value is saved so it does not need to be calculated a second time.
When we should use global variable and when class variable and why?
I hope your experiences and ideas to share with us who are novice in this platform.
Example:
Let, i need to trace timestamp and position of touch events (eg. touch start, end) on a layer. I can trace it using global variable or class variable of the class which implements touch event. What should I do?
Regards,
-Sadat
This isn't a problem specific to Objective C or the iPad family of devices.
Variables should have the minimum "visibility" and "duration" that they need, and no more.
You would have to come up with some very convincing reasons for trying to get a global variable through our code review processes. They're almost always able to be replaced with something a little more appropriate.
In response to your comment:
I don't know how global/class variable affects on memory.
There's a nice snippet over here which details how to do class level variables. These are normal C file-scoped variables so they're not visible outside the file but you only get one for the class, not one for every object that you instantiate.
In that sense, they have the advantages of a global (minimal storage and the value is still accessible for reading) without the disadvantages (polluting the global name-space and making it possible for code outside of the class to change it).
And, if it doesn't need to be read outside of the file, just don't provide the initCount method.
It's kind of a flip answer, but don't use global variables at all - stick with class methods and expected encapsulation. Anything else and you'll be fighting the cocoa libraries from dusk to dawn. If you follow their patterns, which include class methods, encapsulation, delegation, etc - you'll be making huge headway with relatively little effort.
The only place where I might think to call something a "global variable" in my efforts are project-wide constants - so not variables at all, but sometimes there's a good need for a constant across your project (TableViewCell identifiers comes to mind)