I do understand that point of view and largely agree. However, some (pretty small) functions or constants are private to some namespace, or rather, to some scope inside a namespace. I consider the public functions as the 'API of the namespace'. Internals shouldn't be exposed, so I can change internals without having to worry about public access changes. Having everything public would be a real pain and since internals change quite often, like in about 80% of the cases, I'd be torturing myself :p.
So yes, I agree to avoid global privates, but not 'private' in a general sense. Everything binding in a let-special form is like private to that let-block. But > ... is this really private or is it a bit of instance state that really > shouldn't be a global def anyway. > seems to me answering my question: do not use global private defs, but use (top-level?) let-blocks. Thx, qsys Op donderdag 27 augustus 2015 01:15:14 UTC+2 schreef red...@gmail.com: > > I have found the access control stuff in Java to be an incredible pain. > When attempting to compose a larger system from the parts. Generally > everything is compulsively private, so if an api doesn't exactly expose > what you want, you either have to write what you want completely from > scratch, or use reflection to get a the bits you want to compose in to > what you want. > > Avoid private as much as you can, and if you think you can't, ask > yourself, is this really private or is it a bit of instance state that > really shouldn't be a global def anyway. > > When I make the case for making everything public generally the argument > I get back is about api evolution and how do users know what the stable > parts of the api are? I think this concern is a result of using > languages and tooling that don't do a good job of distinguishing source > code used to build an artifact and an artifact. Clojure tooling is > mostly built on top of maven, which does an excellent job of > distinguishing between the two. If you build your code using a jar out > of maven with a fixed version of 1.0.1, unless you change your > dependency you will always get the same code, so who cares what the > author decided is the stable public api and what is the private api. > Anything that you can make use of you can, and it will be the same until > you change it. > > The answer to that is generally something about semantic versioning, > which due to every high profile project that uses it having at some > point a heated argument about what does and does not constitute a patch > release, who knows what you getting anyway. > > -- > And what is good, Phaedrus, > And what is not good— > Need we ask anyone to tell us these things? > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
