On Sat, Nov 14, 2009 at 3:45 AM, Mark Engelberg <mark.engelb...@gmail.com>wrote:
> 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. +1 for ability to specify, especially if it's recognized by tools such as IDEs and they filter private stuff from other namespaces from what they use as possible completions, etc. Particularly, I'm in favor of removing the exception throw when a private var is dereferenced from outside its namespace, particularly as it will solve the macro-expansion-uses-private-implementation-function issue (making the expansion generate the function as a local function or anonymous function seems messy to me when the function's own content does not depend on the macro arguments). Let :private true in a var's metadata influence tools like IDEs and documentation generators, so they don't show as part of the API, and let IDEs give warnings if they see a symbol that resolves to an external private var in your code (though not in the expansions of non-private macros you call). That should suffice to prevent accidental self-inflicted gunshot wounds to the foot, while preserving maximum flexibility. -- 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
