I haven't discussed it specifically, but my thoughts on protection scope are:
if undefined, implied to be public
public: anybody can access
protected: subclasses can access
namespace: classes in namespace can access
private: only available to declaring class
Basically public, protected, private are straight forward, same in Java and in C#.
Java package protected is not quite the same as C# internal, and Java has nothing like protected internal. Not sure what rules the CLR enforces (John you will have to figure that out).
But I think having a namespace scope that works like Java's package protected is very useful. For .NET we can just mark it internal, and let the compiler check use of APIs in the assembly but outside of the namespace.
Making public the default solves the common case (because fields will always be wrapped with getters/setters, more later).
brianThu 8 Dec 2005
I have implemented the protection scope flags as discussed and checked into svn.
They are implemented in parser, Java assembler, and added to the MemberDefTest.
Still to be implemented for CLR.
johnSun 18 Dec 2005
I like the protection scopes that you have defined, but I don't think there should be a default. I think you should have to declare it explictly.
Other than saving a few characters worth of typing I don't see the benefit in having a default and since the proposed default is different from Java I can see that causing some confusion.
brianMon 19 Dec 2005
No way - typing public all the time is a huge pain in the ass! This way it makes Fan more like scripting languages where you don't have to think about it - unless you really want to in which case you can increase the protection.
johnMon 19 Dec 2005
I think it should be required precisely because it does make you think about it.
andyMon 19 Dec 2005
I agree here with Brian - public should be the default, and use protected,private explicitly.
brianMon 19 Dec 2005
That is just the problem, often times I shouldn't have to think about it because I just don't give a crap. It is a library designers tax imposed upon everybody. Consider the compiler code itself - protection scopes add very little to the code, other than some internal interfaces that are just as good documented. When at all possible a feature should be optional and not clutter the syntax if you don't want to use it. In reality I found most methods even in a library are public anyhow, with package scope helper classes or implementation details hidden in other packages.
brian Wed 7 Dec 2005
I haven't discussed it specifically, but my thoughts on protection scope are:
Basically public, protected, private are straight forward, same in Java and in C#.
Java package protected is not quite the same as C# internal, and Java has nothing like protected internal. Not sure what rules the CLR enforces (John you will have to figure that out).
But I think having a namespace scope that works like Java's package protected is very useful. For .NET we can just mark it internal, and let the compiler check use of APIs in the assembly but outside of the namespace.
Making public the default solves the common case (because fields will always be wrapped with getters/setters, more later).
brian Thu 8 Dec 2005
I have implemented the protection scope flags as discussed and checked into svn.
They are implemented in parser, Java assembler, and added to the MemberDefTest.
Still to be implemented for CLR.
john Sun 18 Dec 2005
I like the protection scopes that you have defined, but I don't think there should be a default. I think you should have to declare it explictly.
Other than saving a few characters worth of typing I don't see the benefit in having a default and since the proposed default is different from Java I can see that causing some confusion.
brian Mon 19 Dec 2005
No way - typing public all the time is a huge pain in the ass! This way it makes Fan more like scripting languages where you don't have to think about it - unless you really want to in which case you can increase the protection.
john Mon 19 Dec 2005
I think it should be required precisely because it does make you think about it.
andy Mon 19 Dec 2005
I agree here with Brian - public should be the default, and use protected,private explicitly.
brian Mon 19 Dec 2005
That is just the problem, often times I shouldn't have to think about it because I just don't give a crap. It is a library designers tax imposed upon everybody. Consider the compiler code itself - protection scopes add very little to the code, other than some internal interfaces that are just as good documented. When at all possible a feature should be optional and not clutter the syntax if you don't want to use it. In reality I found most methods even in a library are public anyhow, with package scope helper classes or implementation details hidden in other packages.