ControlType -> None Vs. Module inside Manipulate (i.e. making everything local)

Question

I'm building a program on another one made available in the Wolfram Demonstration Project.

I've noticed that in the original code (working flawlessly) many variables were made local inside the Manipulate wrapper by making ghost controls, i.e.

{var1, ControlType -> None}
{var2, ControlType -> None}
{var3, ControlType -> None}...

and there was no Module instruction inside the Manipulate.

I also found out that, after some changes made by me, the code wasn't anymore behaving well and that the main body of the manipulate command was executed two times after changing a control value.

By trial and error I managed to fix that double execution by inserting a Module command encapsulating a new variable created by me (causing the problem), that was global and that re-triggered the evaluation of the Manipulate body section.

I've read elsewhere that making all variables local inside a Manipulate can be a good programming practice and that guideline actually helped me to pinpoint the problem and avoid the double evaluation issue.

The whole code is too complex and long to be posted here and also to be reduced to a stripped down example.

So my questions are rather theoretical but probably clear enough in their essence to be answered by some Mathematica user more expert than me.

They are:

1) What's the difference (if any) between using a Module or using the ControlType -> None technique?

2) I've some compiled functions inside the Initialization section of the Manipulate. I see that those compiled functions are global and I don't know how to make them local. Do I have to leave them global without worrying much (there's no apparent issue about them till now) or is it advisable to make them local somehow (if so, how)?

Answer 1

My feeling is that this question is probably too broad and a definitive answer might be too long or nearly impossible. This a comment to point out issues to consider in deciding whether and how to localize symbols.

+ Is the application self-contained? Or does it consist of several components that need access to a shared variable (e.g. a database or common utility functions)? Is the notebook going to consist of several independent Manipulate programs whose variables and functions need to be isolated from each other? Could other notebooks opened by the user interfere with your program?

+ Localizing by nesting modules and dynamic modules (including Manipulate which constructs a DynamicModule) can have advantages and disadvantages. When they are nested with Dynamic as well, things can get complicated to explain. Most, if not all, of these are discussed in other questions. See the references below for some of them. It is perhaps worth repeating here that code of the forms

Module[{x}, Manipulate[prog[x],...]]
Block[{x}, Manipulate[prog[x],...]]

is asking for trouble. Note that as of V10, the x is highlighted in red as a warning.

+ Some find the automatic handling of controls and formatting by Manipulate irritating to control and recommend doing it all by hand with DynamicModule. Sometimes one is unaware of exactly what Manipulate is doing, and in complicated Dynamic situations, the lack of awareness can lead to bugs.

+ Similarly SaveDefinitions, another automatic handler, can cause unanticipated problems.

+ It's important to understand what happens in your application when the notebook is first opened by the end user.

+ In short, there are situations where one needs the variables and functions localized and situations where one needs them not localized. For myself, my inclination is to keep the nesting of the DynamicModules to a minimum and put all the variables in the Manipulate or outer DynamicModule, when possible. There are usually fewer problems. For intermediate results, I use nested Withs, which has the advantage of not creating a tracked symbol.

References

Relevant discussion of the issues: What does None mean in a control specification for Manipulate?, Unexpected Setter Bar Behavior when Manipulate Nested in Dynamic Module (note the comments, too)

The issues go back a ways: Manipulate Evaluation Order Problem, Question about scoping data in a multi-level Manipulate construction

And they persist: Manipulate in Manipulate

Initialization and SaveDefinitions issues: DynamicModule, SaveDefinitions and global functions, Working with DynamicModule: Tracking the progress of Initialization

And there are more....