Hacker News Reader

Comment by jgibson | Hacker News Reader

Access modifiers are something that I only ever find to get in the way. I've recently moved to Java from Python for work. The underscore convention in python works fine for hiding stuff from the general public namespace, but its still there if you want to explore how some code or module works. Java really annoys me because I can't access implementation details when I'm trying something out in an interactive shell or debugger, even if I'd never access a private/protected variable in production code

View on HN

The point of access modifiers is to get in the way. They're ways of allowing developers of one part of the source to control what the path of least resistance is for the users of that code.

If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.

It doesn't really matter for small teams, but it's essential for large ones without aggressive (and difficult) enforcement of contract between team members.

`foo._a` accessible outside `Foo` but it makes code look gross and means you're doing something wrong.

`foo.__a` accessible only inside `Foo`

I think it works.

> `foo.__a` accessible only inside `Foo`

It's not all that inaccessible. Try:

    class C:
      def __init__(self):
        self.__private = 'Is it private?'
    
    c = C()
    c._C__private

Double underscore names aren't so much about access control (because access control isn't strongly enforced) as about limiting name collisions (by including the class name in the underlying field name).

Specifically, it's about avoiding collision of "private" names via inheritance.

If you are working with a large team, you need a statically typed language. Access modifiers are the least of your problems, the lack of refactoring support is a much bigger problem.

I agree, but I was focusing on a single aspect and explaining why its value might not be apparent to the parent commenter. Really, the same argument can be adapted to other contentious features of popular static languages.

> If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.

> It doesn't really matter for small teams

Doesn't even have to be your team. We encountered this by way of a major library, celery.

I forget all the details, but celery was importing something else (name started with a "k", I think), and that was importing an underscore-prefixed function from uuid. Somewhere between python versions 2.7.8 and 2.7.13, the implementation of uuid changed and that import failed.

Personally, internal mutation is something you should avoid in general. Pretty hard to avoid in OO languages though.

Reply on news.ycombinator.com