Re: Namespaces, APIs, protocols and records

Thanks for the pointer to tools.namespace — it looks really useful. And if I follow the advice there to "always create new instances of records after a refresh", it will simplify my decision on how to organise namespaces — there's no longer a need to

Re: Namespaces, APIs, protocols and records

Thanks for the suggestion to look at the ClojureWerkz libraries. I took a quick look at the user documentation for three of them (Monger, Welle and Quartzite), and in all cases they showed examples of client code requiring multiple namespaces. On Monday, 15 April 2013 16:45:47 UTC+1, travis va

Re: Namespaces, APIs, protocols and records

> > "...talk by Stuart Sierra (http://vimeo.com/46163090) in which he suggests > putting protocols and their implementations in separate namespaces, > because, during development reloading a protocol breaks existing instances" > I don't universally recommend this any more. You still have to be

Re: Namespaces, APIs, protocols and records

> I definitely like that it keeps things simpler for me (the implementer), but > clients have to know about multiple namespaces rather than a single namespace > and I don't like that. Ah, right - I've mostly been working in application code, not libraries. That said, I think the heuristic still

Re: Namespaces, APIs, protocols and records

I'm considering going this way. I definitely like that it keeps things simpler for me (the implementer), but clients have to know about multiple namespaces rather than a single namespace and I don't like that. I must say I'm finding it hard to decide which way to go. On Monday, 15 April 2013 1

Re: Namespaces, APIs, protocols and records

For what it's worth, I've been refactoring big namespaces out into small, focused namespaces lately. A rough heuristic I've found useful is that when I require a namespace I should be able to assign it a name that aids with readability. So for example: (ns foo.book) (defn search [book term] ;;

Re: Namespaces, APIs, protocols and records

Thanks — this works nicely. I think it's a shame that if I want to make protocol methods public I have to use the "Use implementation namespaces and create an API in a separate namespace" approach, but I guess this is the only way. On Monday, 15 April 2013 01:52:37 UTC+1, Mikera wrote: > > You

Re: Namespaces, APIs, protocols and records

You may want to look at what core.matrix does in this regard: clojure.core.matrix: single namespace containing the public API clojure.core.matrix.protocols: namespace containing all the protocols clojure.core.matrix.impl.* : namespaces for specific implementations / subsystems + a few utility nam

Re: Namespaces, APIs, protocols and records

Whoops — when I said "with an extra [namespace] for each protocol", I meant "with an extra [namespace] for each protocol implementation". On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote: > > I'm in the process of trying to work out how I want to use namespaces when > implementing libra

Namespaces, APIs, protocols and records

I'm in the process of trying to work out how I want to use namespaces when implementing libraries or subsystems. I'm aware of several approaches: - Use a single namespace, making only the API public (either with everything in a single file or breaking things into multiple files and us