Declaring _x as private, __y as public.

[nevdelap]

Hi guys,

I reckon this kind of thing should be disallowed. Any reason it isn't?

class A

    var _x as int is public
    var __y as int is protected

[Charles]

Well you explicitly wrote "is public" so one perspective is that Cobra is simply following your instructions under the assumption that you asked for this for a reason... Maybe it's even temporary while you work on a problem. If it becomes an issue in practice we can add a warning or error (with a -legacy-foo flag for existing code bases).

[nevdelap]

Ok, good idea. Temporary to test something is scenario that makes sense. But certainly a warning is better than allowing it outright. A lot of programmers insist on doing really dumb things, and I think this would fall into that category when not done 'temporarily'.

[hopscc]

I'm interested in hearing your reasons/rationale for stating/believing that the example you gave 'should be disallowed' and is 'a dumb thing to do' .

[nevdelap]

It seems to be a great advantage that you could be able to look at code and know easily from the syntax .a, _b, __c whether you are looking at something that is a public member, a protected member, or a private member.

Is there a good reason why someone should go and circumvent that with var a is protected, var _b is private, and var __c is public?????

The temporary for testing scenario is a good reason, hence Chucks suggestion of putting a warning.

Aside from that good reason it seems pretty self evident to me that deliberately confusing the meaning of ., _, & __ would be dumb, so I don't know how to rationalise it.

Maybe there are more good reasons to do it that I haven't thought of.

Dumb was a poor choice of word. "Dumb things" in this case meant something like "things that make code harder to read where it could easily be avoided and could be prevented", though there are many others, and Cobra goes a long way to preventing loads of them - the antithesis of something like a Perl or a C++. I've done plenty of dumb things in the past myself and when the compiler prevents them I thank it.

[hopscc]

In Line order

1) It is advantageous to assume that the naming convention allows you to make an assumption about accessibility
BUT
you cant know with 100% probability unless the compiler always enforces those (and only those) name forms for those access modifiers
( i.e its on a balance of probabilities not a I-know-this-to-be-so 100% knowledge)

You cant assume a .name is always public cos it could be declared ( is protected/private/....).
Though via convention and emerging idiom thats probably the way to bet...

The _ and __ naming is a convenience for a common convention:

2) circumvention rationale: I've two replies to this

a) I cant think of any but thats no guarantee that noone else can have a good reason for wanting to do so

b) Sure, heres some :

scenario/code std where there are no public member (variables) only protected and private; protected are unadorned (.a), private are leading _ ( _a)
scenario where _ and __ names are anathema, all are unadorned (declared with explicit accessibility) ...
Development : still nailing down accessibility . all start with explicit private accessibility and __named ( to denote still flexible), change declaration typing as determine need
(eventually/maybe/never "correct" naming to conform to convention).
Different convention: .name public, .name_ protected, .name__ private ( trailing _ suffixes rather than leading)

3) Chuck likes warnings and they work fine for cases where the warning is warranted. Where they arent, where you have a good reason for doing something is a slightly different way they become a colossal pita. ( or at least obscure real warnings that you do want to know about).
Warnings are an good guiding mechanism though

4) The ., _ and __ naming isnt a meaning; its a convenience conforming to a (common) convention.
Currently you can use it if you prefer ( or follow the convention), ignore it if not , so long as its not a regulation.

5) Maybe so, maybe there are good reasons none of us have thought of..... Keep that thought (:-).

6) The problem with this line of thought is the possibility that as well as avoiding/preventing the bad thing it possibly precludes a diversity of other things as well .
Its the ' there is only the one best way' vs 'This is one way and preferred but we allow others'
guide vs regulation

[nevdelap]

You seem to have said using a huge amount of words...

"It is only convention because it is only a convention. Is is not regulation because it is not regulation."

All I'm saying is "make it not just a convention and Cobra code will automatically be even clearer and even more unambiguous".

I've never wanted python not to name-mangle a __ member so that I can do something more diverse. And maybe I need the diversity of having classes that start with lower case. (Not really, but same argument.)

[hopscc]

Well that was one of the points, the rest was clumsy attempts at explaining why it might be a good idea to leave it so.. line by line for your posting
Amongst other trivial interpretations you didnt chuck up was "convenience for a convention".

re "all I'm saying... " append "and less flexible or accomodating ".

Oh that reminds me, if you look back at early forum/discussion and cobra versions (pre 0.7.5) you would find that there was an early version that had a mandated naming scheme for
protected vars (had to be leading _) - ask chuck why he changed it.

The key point of any/all of this was in the last two lines
but I though the points and range of examples of why you might not want to force regulate this in 2) was reasonably compelling.
Oh well.

I've only been talking around only member naming (convention) and accessibility relationships here.
(not diverse naming of anything else though ...
"protected classes names must start with an _, private classes names must start with __ "
Hmmm ...
)

[nevdelap]

re "all I'm saying... " append "and less flexible or accomodating ".
- How is the flexibility and accommodation of being able name a public member with double underscores ever going to be good or necessary? I'm not saying it's not, I'm asking. I can't see how it could be, except for obfuscation.

Your 2.
- Why would anyone deliberately make a coding standard that directly contradicts how everything is already done in the language? Or having coding practices that do the same? And I don't buy that you're going to want to mess with all your accessibilities on everything so much that you'd have to let all your names get into a mess because you only have time to change the 'is xxxx' and not rename things.

The earlier post.
- Thanks. I'm studying every post in detail. So I'll get to it. Sometimes it's a problem when I've read older stuff and haven't gotten to the new stuff, but want to ask questions and make comments. Hopefully it wont be too annoying.

"protected classes names must start with an _, private classes names must start with __ "
- Huh?????????????

I'm talking about consistency and the compiler doing as much as possible to make code consistent and help a developer reading code to understand it, and yes - without limiting unreasonably what is possible. But 'there is only the one best way' vs 'This is one way and preferred but we allow others' & 'guide' vs 'regulation' are false dichotomies. You are not advocating "a complete free for all" and I am not advocating "lock everything down so there are no choices in anything".

I will keep thinking about it, but none of it is my decision to make so I'm just discussing ideas. My experience working on projects of up 60 developers who mostly wanted flexibility to accommodate their diversity makes me wary of 'just in case someone wants to X' without specifying what some of the possible Xs are.

[nevdelap]

Damn! I only just noticed. I meant this topic to be called Declaring _x as private or x as public - NOT _x as protected. Probably confused things.