Remove the personal access modifier and make private behave as personal does now.

Jeff Walker (language designer)

jwalker@cs.oberlin.edu

One cannot implement the interface of a class that contains private members. This could be a serious impediment to certain apps that want to generate proxies for all types. The present situation seems to break a sense of symmetry. This would additionally remove the confusing distinction between the private and personal keywords and make private what new programmers expect.

The major concern with this is whether it would prevent the creation of functions like equals that rely on seeing the state of other objects of the same type.

The benefits from this could be great. Dynamic proxies appear in many environments and could be very useful. Examples include networking, mobile object and concurrency. In the case of concurrency they could be used to implement futures, which are values that will be set by another thread and so reading them causes a block on the current thread. These are sometimes implemented so that a future of type T implements the interface of T and is invisible. This will be difficult if there are personal and private members as opposed to only truly private members as proposed in this change.

Note: if it can be proved that there isn't a problem with equals, or a good solution can be found, I would like to accept this proposed change.

jwalker@cs.oberlin.edu