In 6.0 we will not allow function re-use across namespaces. It wasn't supported in the syntax anyway, but people found ways around that, via the class generation conventions we used. In 5.0 we used a composite class loader, which made this possible. But it also has poor performance, and creates complexity in detecting cyclic resolving. We've simplified this in 6.0 by using a tree based CL. One CL per namespace, and one root CL. We put the type declarations in the root CL, so they can be seen from all rules in all namespaces. However things in the root CL cannot be updated, but our type declarations once added have never been modifiable. Functions still remain in the namespace class loader, so only things in that namespace can see them. These functions can be updated. You can now include java classes with our deployable units in 6, so if you want a function visible to all namespaces, simply add it as a static java method. Note that it will not be updateable. When you allow things from one class loader to view things from another class loader, this creates a dependency. To allow updating it means everything in that class loader and all it's dependant references, must be dropped and re-resolved. So while it's possible, it creates complexity in creating these graphs of class loaders, based on their function usage. Especially as a function could be re-used by 1..n namespaces, and a namspace may use 1…n functions. So for now we have kept things simple, and thus more robust and reliable. Mark On 21 Jun 2013, at 20:40, Jeremy Ary <jeremy.ary(a)gmail.com&gt; wrote: