Putting words in the major developers mouths :) The "Julian" way is to have lots of small functions. Automatically exporting all those helper functions pollutes the namespace and increases the chance of name clashes with other packages. So "exportall" would also need an "unexport" or "local" as well to hide these functions. Having spent considerable time in the past adding "static" to C function declarations, I can say with authority that the "local" will be forgotten regularly since it is innocuous until a clash occurs.
Cheers Lex On Saturday, December 6, 2014 11:36:44 AM UTC+10, Greg Trzeciak wrote: > > Hah, thanks for actually bothering to reply with such a simple mistake (in > my proper code I exported with a typo and assumed export doesn't work in > repl) > > Is there any paritcular reason why there is no "exportall"? > > On Saturday, December 6, 2014 12:17:51 AM UTC+1, [email protected] wrote: >> >> You didn't export Foo from the module. >> >> Cheers >> Lex >> >> On Saturday, December 6, 2014 3:23:26 AM UTC+10, Greg Trzeciak wrote: >>> >>> While developing in IJulia notebook (and REPL) if I need to redefine a >>> type I am informed of "invalid redefinition of constant". According to >>> http://julia.readthedocs.org/en/latest/manual/faq/ the types in module >>> Main cannot be redefined and as a workaround it suggests wrapping the code >>> inside the module. But if I do: >>> In[1]: >>> module Mod1 >>> >>> type Foo >>> name::String >>> end >>> a = Foo("bar") >>> println(a.name) >>> end >>> >>> How can I get access to Types defined in In[1] >>> >>> eg. In[2]: >>> using Mod1 >>> b = Foo("bar") >>> println(b.name) >>> >>> ERROR: Foo not defined >>> >>> I tried using, export, import, importall to no avail and placing the >>> code in the .jl file and using include("something.jl") is not an "an >>> excellent workaround" because it defies the purpose of using notebook. >>> >>> I know I can restart the kernel but it is not too practical to do too >>> often. >>> >>> >>> >>> >>> >>>
