sikuli-driver team mailing list archive

[RaiMan <question209132@xxxxxxxxxxxxxxxxxxxxx>]

Question #209132 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/209132

RaiMan posted a new comment:
@ j-the-k
Besides the fact, that the setAttr() (sol1) approach is much more elegant than my suggestion (sol2), there is no difference according "later changes".
In both cases, you decide, what value will be in the myModuleX's global context (sol1: after import, sol2: before import/reload).
In both cases only the addressed (sol1: directly, sol2: doing import after changing extra module) modules will have the changed values.
In both cases the value lives in the global context of the myModuleX's. Changes in one module do not affect other modules.

sol1 is more consistent, since the value is only managed in one place (main module).
with sol2 you could theoretically change the extra module outside in the filesystem, which would affect imports happening afterwards. 

On the other hand:
sol2 is more transparent, obvious and robust: there is a module containing the value, which is imported. Later changes do not affect modules after the import is done.
With sol1, myModuleX contains a variable, where it is not obvious, how it is initialized (this is always the problem with reflection approaches (directly accessing the internal structures of objects)). This is even more critical, if you change the value from main later (hard to find errors, if the problem is in main ;-).

Conclusion: Both solutions do what they should, with sol1 being simpler,
more elegant and having more options.

Sol2 has advantages, if you need more complex module contents, that
needs to be constructed programmatically.

-- 
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.