Nice TWiki > Dev > CurrentDiscussions > VisibilityModifiers (r1.7) 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

In InnerClasses, I mentioned that I use inner classes in Java to emulate Eiffel's selective export language feature. ArjanB? mentioned a "proposal is to give sourcefile access to things with the private modifier." I'm not sure how this works with methods of a class being defined in multiple files, multiple classes methods' being defined in one file, etc., so some of my concerns below may be irrelevent.

I think making all the classes in a single source file the equivalent of friends would be a mistake. It removes nearly all the benefit of visibility modifiers for classes inside one source file, which would end up encouraging a more Java-like one class per file. It makes the most common case difficult in favour of making the less common easy (if not too easy.)

It would also be far coarser grained than an Eiffel-like selective export, becoming all-or-nothing. You could not restrict access to a subset of methods, but would have to either give access to everything or everyone access. For example, you want to give class B access to method Z of class A. To achieve this with the friend-like proposal, you either give class B access to everything of class A, or give all classes access to method Z. Neither choice is ideal. With selective export, you could just list class B in the export list for method Z, instead of specifying public or private.

Further, it makes specialization difficult. By specifically restricting to classes within the same source file it prevents subclasses defined elsewhere (which is how package, friend, and inner-classes work, I don't know about the Nice proposal) from achieving the same degree of flexibility. With selective export, you could create a class C subclassed from class B, and it would still have access to method Z. With package/friend/inner classes, you'd have to actually define class C in the same source file as class B, which is impractical and often impossible (e.g., class B is in a library.)

Selective export is a wonderfully usefull feature, but is all about finesse and fine control. Emulating it with package/friend/etc. is destructive overkill. I'd love to see Nice gain this advantage over Java. I'm not sure how they would interact with multi-methods though.

I must also say that I find it a little unsettling that units of storage, the source file, are being given semantic meaning in the language. While certainly convenient to the language designer, I think it makes the language a bit inflexible.

-- Vulcannis - 28 Aug 2003

The main problem of visibility in nice are multimethods, they do not belong to a class so defining usefull semantics is difficult. I haven't seen any other language with multimethods that has visibility restriction.

-- ArjanB

Topic VisibilityModifiers . { Edit | Attach | Ref-By | Printable | Diffs | r1.15 | > | r1.14 | > | r1.13 | More }
Revision r1.7 - 28 Aug 2003 - 19:06 GMT - ArjanB
Parents: WebHome > CurrentDiscussions
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.