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: > > 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. > > > On Tuesday, November 29, 2016 at 8:57:47 AM UTC-6, kovasb wrote: >> >> 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. >> >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
