On Fri, Nov 13, 2009 at 12:58 AM, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > Coming from a Python background, I don't think access restrictions are > necessary. However, flagging fields as "not meant for use by > outsiders" could be of interest for documentation tools, to make it > clear what client code can safely rely on.
Even Python has the ability to mangle names so that they are effectively private. They aren't truly hidden, but there's no way you'll misunderstand and call a private thing by accident. As a longtime Python programmer, I guess that's the level of privacy I like. In general, I really hate it when it's difficult to tell what parts of an API are the things that the end-user is really supposed to call, and what part of the data you're supposed to access directly versus an accessor method. It bugs me when I call (:real complex) to extract the real part out of a complex number, only to discover later that I was supposed to call (get-real complex) because the accessor is the only "safe way" to get the value I want. I think anything in datatypes or protocols that help library designers separate the data that's safe to access directly from the data that's not, or the functions that are safe to call versus those that are not -- I think that's a good thing. 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. -- 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
