[ticket:108] member scope: visibility

[gauthier]

in cobra there is the shared keyword scoping:

class Program
    shared
        def main
            pass

could it be usefull in cobra for member visibility?

possible way to support that:

struct Credential
    private
        var _login as String
        var _password as String

    public
        pro login from var
        pro password from var

I like the c++ syntax when visibility grouping is usefull,

currently the compiler return with:

Code: Select all

error: Got "private" when expecting def, enum, get, invariant, pro, set, shared, sig, test, or var.

[jonathandavid]

I love Chuck's idea of having members that start with an underscore be protected, members that start with two underscores be private, and all others be public. In fact, I like it so much that I would remove from Cobra the possibility of using the "is private" etc. modifiers. The (few) Cobra code I've written so far shines with respect to its C# equivalent because of the absence of "private, public" etc everywhere. I used to like C# syntax but now it seems too verbose (in addition to conciseness, the underscore convention has the benefit of readability: the visibility of a member it's clear from it's name; you don't have to go to the place it's declared to discover it).

In summary, in my opinion we should go the opposite way. Instead of adding "private", "public" etc blocks as in C++, we should remove the "is private" syntax from the language, and rely only on the underscore convention to modify visibility. I have a similar opinion with respect to shared members, I wish there was an intuitive convention to identify them without having to write "is shared" all the time. I'm thinking of something like adding a ~ suffix to them, but I know it's probably not a practical idea:

class Program
    def main~       # ~ suffix instead of "is shared"
         pass
   
    def _doSomething~         # private and shared
         pass

Regards,
Manuel

[pchapin]

I'm a little concerned that the distinction between one and two underscores would be easy to miss when reviewing code. It seems a little too subtle to me.

[hopscc]

By all means we should provide common conventions for minimising explicit access descriptions for those that like them and want to use them that way
but we shouldnt preclude allowing explicit ( clear) syntax for the same thing ( for those that dont)
i.e
The underscore naming ( and any others added) are a shortcut not a replacement for the explicit descriptive syntax ( is ...)

(for example re manuals 'is shared' I like the idea theoretically but dislike the exact suggestion for syntax ( ~ suffix) )

Its been mentioned extending the blocking for the other access modifiers over and above 'shared' but its not been looked at for implementing yet...
I'm wondering how well it would work with cascading combinations of modifiers ( is shared, private, ... ( +const).

The use of (double) underscores is a choice .. if its difficult for reviewers theres always the reccommendation to use the explicit is protected/is private form

[pchapin]

The underscore naming ( and any others added) are a shortcut not a replacement for the explicit descriptive syntax ( is ...)

Of course having two ways of saying the same thing has disadvantages too. It can be unclear for programmers who are not familiar with or used to the way they haven't used before.

[jonathandavid]

(for example re manuals 'is shared' I like the idea theoretically but dislike the exact suggestion for syntax ( ~ suffix) )

I tried a few alternatives and this was the one that looked best to me. I'm not sure I like either. Besides, the choice of ~might be a nightmare for the parser. Think of an expression like a.foo~ 4. Is ~ part of the method name, or is foo a parameterless method and ~ is applied to 4?

[gauthier]

abstract/override/nonvirtual scope would be great too:

class A
    is abstract
    abstract
        def foo
        def bar
class B
    inherits A
    override
        def foo
            pass
        def bar
            evilMethod
    nonvirtual
        def evilMethod
            pass

[Charles]

I don't see any problems with that. If "shared" and "private" can be used for sections, why not "abstract" and "override"?