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

"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))) ]

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