Nice TWiki > Dev > NiceDiscussions? > VisibilityModifiers (r1.4) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
What should be the exact semantics of the VisibilityModifiers?

Can VisibilityModifiers added to method declarations or method implementations or both?

How do VisibilityModifiers affect where you can implement and/or call methods?

I have thought about this but I didn't get consistent and usefull semantics. The only easy ones are the global constants.

Anyone some good ideas?

-- ArjanB - 09 May 2003

It's also easy for functions (unless we have FunctionsReplacedByMultiMethods, in which case the question disappears).

For methods, I think that visibility only makes sense to method declaration. It should restrict the places from where you can call the method. I don't think that we can/should restrict the places you can implement the method, because I believe that in some situations you would need to implement a method where it is not accessible.

Similarly for classes, visibility should not restrict implementing a method for that class. I can see too usages for non-public classes. One is to make the constructor restricted, which means you cannot instanciate them outside the scope. The other is that you cannot use them in types. The first one is surely needed (singleton pattern). I'm not sure about the second. A possibility is that both would be restricted. I think the second one is too restrictive to be useful in practise.

- DanielBonniot - 10 May 2003

The simplest solution is to make VisibilityModifiers only affect the places where you can call a method/constructor. I think there should also be a way to restrict the places where you can implement a method. Implementing a simple form of the VisibilityModifiers first and using them will give more insight in what kind of additional restrictions are needed.

-- ArjanB - 03 Jun 2003

Agreed. I thought that a good way to start implementing this would be to develop an independant library for managing symbols with visibility properties. That would help keeping the complexity out of the compiler, and thinking abstractly. It should probably be implemented in Nice, but keep in mind might be called by some Java code. Anybody feels like working on this?

One feature that I find useful is when "invisible" symbols are not completely ignored, but the system can tell you "foo is defined in package bar, but it is not public". Something to keep in mind is that we might want to have different visibility for the same symbol in different contexts (ex: a field that is public when reading it, but private when writing it). That could come in a second phase, though.

-- DanielBonniot - 04 Jun 2003

Topic VisibilityModifiers . { Edit | Attach | Ref-By | Printable | Diffs | r1.15 | > | r1.14 | > | r1.13 | More }
Revision r1.4 - 04 Jun 2003 - 21:06 GMT - DanielBonniot
Parents: NiceDiscussions?
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.