> I don't really care how strictly the language *enforces* that > separation, but I think the ability to specify that separation is a > good thing.
I'd go so far as to request that it does not enforce separation. I'm sure anyone who's spent enough time using Other People's Libraries has hit instances where the only way to get things to work is to use the (lower-level, undocumented) API because the high-level API doesn't allow you to pass some crucial parameter, or where you need to reuse some internal function or spend the time to rewrite it yourself. In an ideal world (read: fantasy land) you can just fix the library and send a push request on GitHub, but we rarely live in that place. Similarly, I'm sure lots of people have had tons of 'fun' with final classes, private and protected members, and so on in Java... "if I could just call that method...". I recall several experiences where if I could have called a protected method I could have worked around a bug in an application server. Instead, I had to patch their runtime libraries, and wait a few weeks for the change to roll upstream. > As a longtime Python programmer, I guess that's the level of privacy > I like. As a Common Lisper and Python programmer, I'm quite fond of this too... "there but hidden". I like CL's package support for this kind of situation, where unexported symbols can still be reached via foo::bar, at the cost of an obvious "code smell". To *really* enforce hiding, you can actually unintern symbols, rendering the things they named unreachable. Unusual, but possible. -- 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
