This is more like a pure Ruby question, and may be naive, but I would like to hear some opinions about what’s the best way to handle this situation.
Let’s say I create a global or a module variable in my plugin because I want to have it accessible from all the module scope. Even if we encrypt the script code, the methods of the module can be accessed from the Ruby Console via Module::method. Accessing methods is fine but, what is the best way to prevent these variables from being seen/modifed from the console?
Whatever you do, don’t use globals. They are not allowed in the SketchUp environment as it is shared between scripts made by different authors and can collide.
Regarding visibility you can mark constants, and perhaps also variables, as private. However they can still be seen from elsewhere, e.g. using instance_eval. Visibility in Ruby is more of a way to state intent than actually preventing other people from accessing. To my knowledge there is no way to hide something in Ruby, except the what is inside the body of a method.
To recommend a good solution, it would be helpful to know just why you are worried about this. What is the issue that would arise if a user could see/modify these variables via the Ruby Console? Yeah, they could probably cause the code to malfunction and maybe even crash, but that affects only them…
Thank you all for the replies, there are some quite interesting ideas that will help me trying different solutions.
@slbaumgartner, the reason is basically the one you pointed. I want the user to access the methods freely but also to prevent the modification of the module variables. This is because some of these variables are accessible from different methods in the module scope and changed dinamically due to the workflow of the plugin. I don’t want a user to see this variables and to change them manually causing a crash (it happened already).
I’m also thinking in other way to handle and structure this situation, avoiding module and class variables.
I’d say, write the code the way it is easiest to understand and maintain. If people manually change variables inside your code, and you haven’t explicitly documented it as a public API, they deserve all the crashes and model corruptions they can give themselves.