www.digitalmars.com         C & C++   DMDScript  

D - default visibility of class members

reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
What is the default visibility for class member variables (or static ones) ?
(it should be private)
Jan 26 2003
parent reply Antti Sykari <jsykari gamma.hut.fi> writes:
"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
Jan 27 2003
parent reply "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.


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
Jan 27 2003
next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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


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
Jan 27 2003
next sibling parent Bill Cox <bill viasic.com> writes:
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

 
 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
Jan 27 2003
prev sibling next sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"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



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
Jan 28 2003
parent Jeroen van Bemmel <Jeroen_member pathlink.com> writes:
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
Jan 28 2003
prev sibling next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"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.


What if we break the C++ paradigm a little:
    * if the class includes *no* public/private/protected marks, then:
        * all data is protected (NOT private)
        * all functions (including properties and ctors) are public
    * if the class includes *even one* public/private/protected, then:
        * there must be a leading mark to "set the default", and it works like
C++

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jan 29 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b13tqt$2b6p$1 digitaldaemon.com...

 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++.


In D, members are public by default. There are several reasons for this:
1) In lines up with C's use.
2) Having to type public: all the time can get to be annoying for many
classes & structs.
3) I tend to view private/protected as an advanced technique, appropriate
for when you're
refactoring your code after it works.
4) class {
  public:
        ...
}
just doesn't look that great aesthetically, especially if the class has only
one or two members.



 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 look at it the other way around. D does it the right way, it's so
straightforward that most won't even notice it working the way they
intuitively expect. C++ has this massive 'friend' kludge with all kinds of
weird lookup rules (do you know what class name friend injection is?). C++
simply got it wrong.



 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.


That's why I regard it as a more advanced technique.
Feb 10 2003
prev sibling next sibling parent reply Bill Cox <bill viasic.com> writes:
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
Jan 27 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Jan 27 2003
parent Bill Cox <bill viasic.com> writes:
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
Jan 27 2003
prev sibling parent "Ken Carpenter" <kencr shaw.ca> writes:
I think the firewall model is the best choice.  Don't grant any permissions
to outsiders without explicit instructions to do so.  In other words, make
everything in a class private as Jeroen suggests.

If you want something to be made accessible to others, then is it really so
hard to type "public"?  You only have to do it once for each method or
member when you write it.  In my Java code, every single method and member
has a public or private in front of it.  It makes it pretty darn clear when
looking at the source code.  I don't have to look back up and see if I'm
within a "public:" or "private:" section, like in C++.

If you make things public by default, then the programmer doesn't have to
think about whether the method/member SHOULD really be public.

Also, I find that excess names just make a class harder to use, especially
with IDEs that have method/member name completion.  All those extra names
get listed in the pop-up window that appears after typing a period.  Yuck.

And as for making methods default to public and members default to private,
it's just going to add extra confusion where there is no need for any.


Ken Carpenter
Jan 29 2003