Timeline for Module inside Module. Conflict of names in arguments
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 16, 2017 at 10:37 | vote | accept | Nasser | ||
| Aug 13, 2017 at 22:27 | answer | added | C. E.♦ | timeline score: 2 | |
| Aug 13, 2017 at 21:46 | comment | added | Nasser | @C.E. Well, ok. But this is all too complicated and overkill for wanting to just have internal function. You can see how easily this is done in Maple for example. But thanks for the idea. | |
| Aug 13, 2017 at 21:41 | comment | added | C. E.♦ | @Nasser It doesn't have to be flat. You can have a hierarchy of packages. If you load a package inside a package, then it won't be available outside the package into which it was loaded. (See "private import" here.) | |
| Aug 13, 2017 at 21:00 | history | tweeted | twitter.com/StackMma/status/896838899116511232 | ||
| Aug 13, 2017 at 20:38 | comment | added | Nasser | @CarlWoll I really like internal functions. They help organize code by putting code where it only needs to be seen. Having everything in flat name space is generally not a good idea IMHO. Using a package will just move the problem from cluttering the global context to the package context. This helps a little, but it will not change the overall design of the program in terms of having helper function inside a module where they are only needed. Ok, I understand this is how Mathematica works. Module in Mathematica sematics are different from traditional programming languages I've used before. | |
| Aug 13, 2017 at 20:33 | history | edited | Nasser | CC BY-SA 3.0 |
fixed typo in title
|
| Aug 13, 2017 at 19:27 | comment | added | Carl Woll | What is the problem with having helper functions outside the module? If you don't like having the helper functions cluttering your namespace, than just create a package so that the helper function clutter the package namespace. If you don't like using helper functions at all, and just like having a single monolithic program, then I think you are headed down the wrong path. It is much easier to develop and unit test individual helper functions. | |
| Aug 13, 2017 at 19:23 | comment | added | Nasser |
@CarlWoll how is using a package will make it easier to move the helper functions inside the module? Will not the same issue be there, but now everything is inside a new context? My main goal was to see if I can have small helper functions inside the module that uses them, not outside. So if I have 2 modules, each uses different helper functions, and there is no shared helper function, I wanted to move these inside. I am not following what you say about memory leak and having to define boo each time parent module is called. Too advanced for me to understand now. Thanks,.
|
|
| Aug 13, 2017 at 19:15 | comment | added | Carl Woll |
Why not just create a package? Also, I think using SetDelayed in this way inside of a module is better avoided. For your example, if boo doesn't depend on the arguments to foo, then foo has to work harder because it defines boo every time it is called, instead of having boo defined once. Also, if boo is ever left unevaluated, either in the output of foo or in a side effect, then boo will never get removed, causing a memory leak. Finally, it is much harder to debug boo when it is defined in a Module.
|
|
| Aug 13, 2017 at 18:14 | history | edited | Nasser | CC BY-SA 3.0 |
added one more example
|
| Aug 13, 2017 at 18:09 | answer | added | Michael E2 | timeline score: 4 | |
| Aug 13, 2017 at 17:50 | history | edited | J. M.'s missing motivation♦ |
edited tags
|
|
| Aug 13, 2017 at 17:48 | history | edited | Nasser | CC BY-SA 3.0 |
typos and fixed image
|
| Aug 13, 2017 at 16:12 | history | asked | Nasser | CC BY-SA 3.0 |