On 2006-07-12 06:17:27, mystilleef wrote: > But developers tend to pay more attention to given methods/functions > less crappy names, at least when compared to data attributes. This > stems from the fact that in many languages data attributes aren't > usually part of the API, as well as the whole OO(Encapsulation) blah > blah.
I'm not sure about which languages you are talking (pretty much all that allow public methods also allow public attributes), but in general I think you should get away from the distinction attribute vs method (which doesn't make much sense in any language) and start looking at the distinction public vs private (which is what you really are talking about) -- and start giving the appropriate care to naming public entities, no matter /what/ they are. (Besides, I don't know many coding rules that say that creating an accessor get/setTemporaryBuffer that acts on the private member tmp is good style.) I'm just starting to get started with Python, but it seems that the leading underscore marks private entities. So why don't you precede everything with an underscore that doesn't have a name that fulfills your criteria for a decent public name -- no matter what kind of entity it is? It seems you are basically complaining that you used a crappy name in a public API. Well... you shouldn't, not in Python, and not in any other language :) And there's no way around it, not in Python, and not in any other language, than to rename that entity in the public API. Which can be a major hassle, close to impossible. There are all kinds of public APIs with crappy names (using accessors and all :) that got created early on and never changed. Stuff happens. Maybe you didn't know about the underscore way to mark private entities. Maybe this doesn't work as I think it does (from reading this thread). But maybe it does, and maybe that's then just part of the learning curve for you. (And I'm sure you're not alone... :) Gerhard -- http://mail.python.org/mailman/listinfo/python-list
