s/def: Rationale, tradeoffs? When to emulate this pattern?

[kovas boguta]

Spec is surprisingly easy to grok given how much it does. 

s/def jumped out at me as an out-of-the-box choice, that I could not immediately rationalize. 

So I'm wondering: why not just use standard def? What does one gain/lose?

This is not just an academic question. Lots of people like me look at Clojure's APIs as an example to follow, so now I'm wondering when I should make the same choice.

I asked Rich about this at the Lisp NYC meetup, the response was to the effect of "vars are already overloaded, lets use a separate database", which makes sense but the implications of that are not clicking. 

[Alex Miller]

At the risk of repeating what you already said, we are pushing too much stuff onto vars and var meta. We have namespaced names so there's no reason to push more stuff into vars and we can use an independent registry.

[Leon Grapenthin]

The registry is stored in a global atom which is usually considered an anti-pattern in library code. It makes sense here though, based on the idea that global conflicts are avoided by namespaced keywords.

What bothers me though is reloadability. When I hit clojure.tools.namespace.repl/reload-all, I potentially end up with zombie specs which can have unexpected effects (note s/keys allows undefed kws). Not wanting to hijack this thread, but is this gonna be resolved in ctn or somehow?

Kind regards,

 Leon.

[Leon Grapenthin]

While I can follow "we have namespaced names" I find it difficult to follow "too much stuff onto vars and var meta". I feel this is what OP is asking for.

- What is meant by "too much"? When is var metadata "too much"?

- What problem can/did result from "too much"?

- Why is this assumed limitation always stated as primary motivation? Are there not other reasons like enabling non var-tied specs like for keywords?

- Have s/fdefs been considered for vars? What is the reason/intended use for s/fdefs in the global registry?

Kind regards,

 Leon

On Tuesday, November 29, 2016 at 5:16:36 PM UTC+1, Alex Miller wrote:

[Alex Miller]

Answers below are my perspective. I have no doubt that Rich would give you better ones. :)

On Tuesday, November 29, 2016 at 1:55:59 PM UTC-6, Leon Grapenthin wrote:

While I can follow "we have namespaced names" I find it difficult to follow "too much stuff onto vars and var meta". I feel this is what OP is asking for.

- What is meant by "too much"?

More than we have now.

 

When is var metadata "too much"?

Var meta gets compiled into the bytecode. This affects compiled code size and more importantly loading time. Also related to load time are vars which are loaded and initialized when a namespace is loaded. These are real costs that affect startup and load times.

 

- What problem can/did result from "too much"?

Load time. Compiled code size. Abusing vars as "the one place to hang everything".

 

- Why is this assumed limitation always stated as primary motivation? Are there not other reasons like enabling non var-tied specs like for keywords?

I don't understand the question. When you have namespaced names, you can create many registries for different purposes and stop using vars as The Registry. There may be other things that could be "registries" as well, rather than being tied only to vars.

 

- Have s/fdefs been considered for vars? What is the reason/intended use for s/fdefs in the global registry?

Same reasons, same answers.

[kovas boguta]

Thanks for the responses. 

One reason might be that with var-bound specs, one could not precisely report the the path to the failing spec. If spec composition is achieved through var resolution, than that name is gone by the time the spec datastructure is composed. 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.