Open borkdude opened 4 years ago
From Slack #sci:
I think there are ... options here.
first: make all the def defns and split them into smaller parts, e.g.
clojure-set-bindings
,clojure-walk-bindings
etc.
- have a global def collecting all in
sci.core
and create a new entrypoint ns, likesci.custom
that doesn’t have the def, but an api that requires the bindings as parameter
- have a compiler switch (
:closure-defines
/:jvm-opts
) which allow to empty the default registry- macro-time select-keys, might work, tested something like this, coudn’t get it to work
Example of option 2 done In malli.
1 could have api like:
(require '[sci.api])
(require '[sci.namepaces :as n])
(require '[clojure.walk :as walk])
(def sci-eval
(sci.api/evaluator
{:bindings (merge (n/cloure-core-bindings)
(n/clojure-set-bindings)
{'walk (n/copy-var clojure.walk/walk...)})})
(sci-eval "(int? 1)")
; => true
I think the option to programmatically create the namespaces.cljc file (to limit access to core vars) is an interesting one. What would happen btw if you right now would include sci.impl.namespaces.cljc in your own project and just edited, ripped out the vars you don't need? I guess that would already work as of now
The sci.api/evaluator
could also do #369 optimization behind the scenes.
tested with dropping all var-mappings from namespaces
.
Before:
After:
empty is not anyway useful, but I think it shows the limit how small it could go. The useful minimal would be much bigger.
I think the idea that @ikitommi has:
The namespaces.cljc file contains top-level datastructures with all the core namespaces in it. Those should be lifted into a function and then users can do a select-keys or dissoc on those namespaces, and making a top-level value out of that. That should help.
Also, we have an addons.future namespace to optionally include future functionality. That's also a way to get access to opt-in functionality.