Enforce privacy. about ponyc HOT 9 CLOSED

Names should be restricted to the following forms:

Foo - public type
_Foo - private type
foo - public non-type
_foo - private non-type

In particular leading double underscore or underscore followed by a digit are not allowed.

The lexer should just accept all of these and the correctness pass should verify them.

from ponyc.

What about structural types and private methods? Obviously, this isn't an issue for private fields, but for methods, there is no way to determine which package a type that has been passed as a structural type was defined in (other than with an runtime check, which isn't what we're looking for).

That means a structural type can expose private methods outside the package.

Should we disallow private methods in structural types? I'm thinking yes, we should. That way, anonymous types never expose access to class internals.

from ponyc.

I've put this in as denying private method lookup on structural types. We can revisit this later if we need to, of course.

from ponyc.

I agree, structural types should not have private methods. A structural type is an inteface, just like a trait, so they don't need private methods which are internal.

from ponyc.

Ok, great. Right now, it only catches that on lookup. Should we be more aggressive, and disallow it when the structural type is defined?

from ponyc.

I agree on this. Generally, if think type checking should always be as aggressive as possible. There is no point it seemingly allowing the declaration/definition, but then throw an error on lookup.

from ponyc.

We should definitely be more aggressive on this. It would be easy to check structural types (and also traits) for private methods in either the parse_fix or scope passes. Scope probably makes more sense logically.

from ponyc.

Ok sounds good. Andy, can you handle it?

from ponyc.

I handled it in the scope pass.

from ponyc.