What is the default visibility for class member variables (or static ones) ?
(it should be private)

"Jeroen van Bemmel" <anonymous@somewhere.com> writes:

> What is the default visibility for class member variables (or static ones) ?
> (it should be private)

Or it should be public, depending on whom you ask.

Please justify your opinion.

-Antti

> > What is the default visibility for class member variables (or static
ones) ?
> > (it should be private)
>
> Or it should be public, depending on whom you ask.
>
> Please justify your opinion.
>
I feared I would be stating the obvious, but as you request it:
public member variables break object encapsulation and are often considered
bad design practice. Although it should be possible to create them (using
explicit 'public') the language should discourage their use, hence default
private unless stated otherwise

In addition, implicit public could potentially introduce bugs since you can refer to a variable without being aware of it. Scope of variables in general should be as narrow as possible, both from an optimizing compiler's point of view, for coding tools such as syntax-dependent completion, and for the programmer him/herself

But public member *functions* should be the default.  Esp. ctors since it's quite annoying to type out a class and have the compiler tell you "cannot access ctor". Grrr!

Since we cannot have two different defaults, one for member variables and one for member functions, we have to pick.

May as well have no default and force the programmer to specify.  At least we don't have to specify on every single declaration like C#.  ;)

I personally find it restrictive and annoying that by default, nobody has access to anything, so the class is worthless unless I specify otherwise. Usually my classes are used by *something*, so *have* to have some public member functions at least.  Therefore public should be the default, because without public members, a class is utterly worthless to the outside world; they can't even create an object of said class.  I find that my classes have more public members than private members, on average (functions, not variables).  In fact I've heard arguments that suggest data hiding (via "private") is bad;  it's better to wall off the object with a method call or something so that the user programmer never even sees the class declaration. That's better for link times in C++.  And if you make everything private in the interface, it's a PITA to actually deal with the object in the implementation if there are several classes involved, they all have to be friends or something.  (In D you get around that by having them all in the same module, so it's no big deal.)  I'm skeptical of the value of the private keyword in general;  I find that it's one of the biggest pains in programming, deciding what to make private, what to encapsulate, what to expose.  For me it's not a big deal since the only users are other parts of my game code, and I can just change them if I change the public interface. For a library programmer it is something to consider carefully.

One way to do it is to have a public interface with only public methods and a private implementation class with only public members.

Anyway it's not entirely a cut and dried issue.

Sean

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b13oco$27u0$1@digitaldaemon.com...
> > > What is the default visibility for class member variables (or static
> ones) ?
> > > (it should be private)
> >
> > Or it should be public, depending on whom you ask.
> >
> > Please justify your opinion.
> >
> I feared I would be stating the obvious, but as you request it: public member variables break object encapsulation and are often
considered
> bad design practice. Although it should be possible to create them (using explicit 'public') the language should discourage their use, hence default private unless stated otherwise
>
> In addition, implicit public could potentially introduce bugs since you
can
> refer to a variable without being aware of it. Scope of variables in
general
> should be as narrow as possible, both from an optimizing compiler's point
of
> view, for coding tools such as syntax-dependent completion, and for the programmer him/herself

Hi.

Jeroen van Bemmel wrote:
>>>What is the default visibility for class member variables (or static
>>
> ones) ?
> 
>>>(it should be private)
>>
>>Or it should be public, depending on whom you ask.
>>
>>Please justify your opinion.
>>
> 
> I feared I would be stating the obvious, but as you request it:
> public member variables break object encapsulation and are often considered
> bad design practice. Although it should be possible to create them (using
> explicit 'public') the language should discourage their use, hence default
> private unless stated otherwise
> 
> In addition, implicit public could potentially introduce bugs since you can
> refer to a variable without being aware of it. Scope of variables in general
> should be as narrow as possible, both from an optimizing compiler's point of
> view, for coding tools such as syntax-dependent completion, and for the
> programmer him/herself
> 
> 

I'd just like to state that on the pragmatic side, I've never had to fix a bug that got introduced by some other programmer who decided to access a field that should really be have been private.  The reverse, however, is often maddening.  Sometimes there's data in a class I need, and the author didn't think to make it public, or write a wrapper.

I think that my productivity would actually increase if public, private, and const were dropped.  I think these are good examples of solutions that make good logical sense, to problems that don't really cause productivity loss.

Again, I'm not really suggesting that these features be dropped...

Bill Cox

Hi.

Sean L. Palmer wrote:
> But public member *functions* should be the default.  Esp. ctors since it's
> quite annoying to type out a class and have the compiler tell you "cannot
> access ctor". Grrr!
> 
> Since we cannot have two different defaults, one for member variables and
> one for member functions, we have to pick.
> 
> May as well have no default and force the programmer to specify.  At least
> we don't have to specify on every single declaration like C#.  ;)
> 
> I personally find it restrictive and annoying that by default, nobody has
> access to anything, so the class is worthless unless I specify otherwise.
> Usually my classes are used by *something*, so *have* to have some public
> member functions at least.  Therefore public should be the default, because
> without public members, a class is utterly worthless to the outside world;
> they can't even create an object of said class.  I find that my classes have
> more public members than private members, on average (functions, not
> variables).  In fact I've heard arguments that suggest data hiding (via
> "private") is bad;  it's better to wall off the object with a method call or
> something so that the user programmer never even sees the class declaration.
> That's better for link times in C++.  And if you make everything private in
> the interface, it's a PITA to actually deal with the object in the
> implementation if there are several classes involved, they all have to be
> friends or something.  (In D you get around that by having them all in the
> same module, so it's no big deal.)  I'm skeptical of the value of the
> private keyword in general;  I find that it's one of the biggest pains in
> programming, deciding what to make private, what to encapsulate, what to
> expose.  For me it's not a big deal since the only users are other parts of
> my game code, and I can just change them if I change the public interface.
> For a library programmer it is something to consider carefully.
> 
> One way to do it is to have a public interface with only public methods and
> a private implementation class with only public members.
> 
> Anyway it's not entirely a cut and dried issue.
> 
> Sean

I agree.  In fact, when I write C++ code around here, I use struct instead of class (only difference: public is default), and then don't bother making anything private.  I still write the get'ers and set'ers, so don't think I want people accessing my internal stuff.  Our programmers are smart enough to use the access functions and leave the fields alone.  Why bother with the extra lines if it doesn't help developers in some real manner?

Bill

Bill Cox wrote:
> I think that my productivity would actually increase if public, private, and const were dropped.  I think these are good examples of solutions that make good logical sense, to problems that don't really cause productivity loss.

I like it when it's properly handled; I wish there were better recourses than either fuming at the stupidity of the original coder whose code you can't modify (private) or having to write your own subclass and possibly even force-casting objects to get to the fields (protected).  There's also legitimate cases where you want the public front of an API over many files but have an internal API that they must all communicate with.  For example, my dig GUI library is intended to be cross-platform, so there's lots of platform-specific fields and methods that shouldn't be public but have to be.  I resisted it for awhile, but eventually had to put "// private:" in the code.  At least they're not documented, but I don't want them showing up in a class browser normally.

I want to be able to cast off protection; I suggested "cast (public) x" months ago.  Walter responded to that by making all objects accessible within a module; I think that's a bad idea as it discourages modularisation.  It certainly doesn't help me as I'm not going to make a 531kb module.

Subject hijacking!  I don't like any of the weird "x (y) z" syntaxes in D; they're all hard to read and each has different precedence, there's no consistency to them, and I think they all look and behave worse than their more language-consistent alternatives.  I think we should have:

- "cast (x, y)" instead of "cast (x) y".  This just looks horrible in practice.  I have no idea what precedence it has, and I have a rule against learning precedence past the BEDMAS level (important for allowing portable compiling, but it's not intended to be learned), so I end up doing "(cast (x) y)".  What a mess.

- "new (x, y)" instead of "new x (y)".  Allocating a list would be "new (int [], x)" - array handling in new has an inconsistent syntax; they mean something entirely different from what a declaration would indicate.  Calling a method on a created object requires bracketing it such as with "(new Foo ()).run ();", which is nobody's expectation, but a requirement of the precedence.

- "x (y)" instead of "instance x (y)", or at least "instance (x, y)". This has the same problem as new, although I don't think it's as visible as the precedence looks different.  I don't know, I haven't used D templates; my usefulness threshold is very low for them.  If they aren't making my client code smoother and cleaner, I won't use them.

Hi, Burton.

Burton Radons wrote:
> Bill Cox wrote:
> 
>> I think that my productivity would actually increase if public, private, and const were dropped.  I think these are good examples of solutions that make good logical sense, to problems that don't really cause productivity loss.
> 
> 
> I like it when it's properly handled; I wish there were better recourses than either fuming at the stupidity of the original coder whose code you can't modify (private) or having to write your own subclass and possibly even force-casting objects to get to the fields (protected).  There's also legitimate cases where you want the public front of an API over many files but have an internal API that they must all communicate with.  For example, my dig GUI library is intended to be cross-platform, so there's lots of platform-specific fields and methods that shouldn't be public but have to be.  I resisted it for awhile, but eventually had to put "// private:" in the code.  At least they're not documented, but I don't want them showing up in a class browser normally.
> 
> I want to be able to cast off protection; I suggested "cast (public) x" months ago.  Walter responded to that by making all objects accessible within a module; I think that's a bad idea as it discourages modularisation.  It certainly doesn't help me as I'm not going to make a 531kb module.

I kind of like module level access.

> Subject hijacking!  I don't like any of the weird "x (y) z" syntaxes in D; they're all hard to read and each has different precedence, there's no consistency to them, and I think they all look and behave worse than their more language-consistent alternatives.  I think we should have:
> 
> - "cast (x, y)" instead of "cast (x) y".  This just looks horrible in practice.  I have no idea what precedence it has, and I have a rule against learning precedence past the BEDMAS level (important for allowing portable compiling, but it's not intended to be learned), so I end up doing "(cast (x) y)".  What a mess.
>
> - "new (x, y)" instead of "new x (y)".  Allocating a list would be "new (int [], x)" - array handling in new has an inconsistent syntax; they mean something entirely different from what a declaration would indicate.  Calling a method on a created object requires bracketing it such as with "(new Foo ()).run ();", which is nobody's expectation, but a requirement of the precedence.
> 
> - "x (y)" instead of "instance x (y)", or at least "instance (x, y)". This has the same problem as new, although I don't think it's as visible as the precedence looks different.  I don't know, I haven't used D templates; my usefulness threshold is very low for them.  If they aren't making my client code smoother and cleaner, I won't use them.

I tend to agree with all these, accept for dropping the instance keyword, which could cause the expression to be confused with a function call.

Bill

"Sean L. Palmer" <seanpalmer@directvinternet.com> ha scritto nel messaggio news:b13tqt$2b6p$1@digitaldaemon.com...
> But public member *functions* should be the default.  Esp. ctors since
it's
> quite annoying to type out a class and have the compiler tell you "cannot access ctor". Grrr!
>
> Since we cannot have two different defaults, one for member variables and one for member functions, we have to pick.
>
> May as well have no default and force the programmer to specify.  At least we don't have to specify on every single declaration like C#.  ;)

This is speaking!
I personally think: "if there isn't an obvious default, then there MUST NOT
be a default, because any default you choose is wrong for most cases".

Ciao

In article <b15muc$b3d$1@digitaldaemon.com>, Roberto Mariottini says...
>>
>> Since we cannot have two different defaults, one for member variables and one for member functions, we have to pick.
>>

Why not? I would be perfectly happy to give member functions public access by default, and variables private