From what I have seen so far, if an access attribute is omitted, then access is public. Is that on purpose or will it be fixed in later versions with private as the default access ?

Achilleas Margaritis wrote:
> From what I have seen so far, if an access attribute is omitted, then access is
> public. Is that on purpose or will it be fixed in later versions with private as
> the default access ?

IMHO public is the correct default. Every class will have public fields, but not all of them have private ones. Besides, private fields belong at the end of the class definition, after the public fields, since a reader of the class should not be concerned with them.

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c7ocbg$7ij$1@digitaldaemon.com...
> Achilleas Margaritis wrote:
> > From what I have seen so far, if an access attribute is omitted, then
access is
> > public. Is that on purpose or will it be fixed in later versions with
private as
> > the default access ?
>
> IMHO public is the correct default. Every class will have public fields, but not all of them have private ones. Besides, private fields belong at the end of the class definition, after the public fields, since a reader of the class should not be concerned with them.
>
> Hauke

I couldn't disagree more. Safety is the primary concern nowadays. Private should be the default access attribute...it is better to forget a 'private' than to forget a 'public': in case an access attribute is ommited, the public access may propagate to the final product and go unnoticed (since everybody would think that it has been correctly set to private). If the default was private, there would be no problem.

Furthermore, what do access attributes have to do with the order they are declared ? if a piece of code is designed correctly, a reader should look at the documentation, and never at the code.

Achilleas Margaritis wrote:

>"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
>news:c7ocbg$7ij$1@digitaldaemon.com...
>  
>
>>Achilleas Margaritis wrote:
>>    
>>
>>>From what I have seen so far, if an access attribute is omitted, then
>>>      
>>>
>access is
>  
>
>>>public. Is that on purpose or will it be fixed in later versions with
>>>      
>>>
>private as
>  
>
>>>the default access ?
>>>      
>>>
>>IMHO public is the correct default. Every class will have public fields,
>>but not all of them have private ones. Besides, private fields belong at
>>the end of the class definition, after the public fields, since a reader
>>of the class should not be concerned with them.
>>
>>Hauke
>>    
>>
>
>I couldn't disagree more. Safety is the primary concern nowadays. Private
>should be the default access attribute...it is better to forget a 'private'
>than to forget a 'public': in case an access attribute is ommited, the
>public access may propagate to the final product and go unnoticed (since
>everybody would think that it has been correctly set to private). If the
>default was private, there would be no problem.
>  
>
Why not use:

class A
{ private:


}

In all your D codings.

This is one of those very insignificant issues that really has no right answer. I doubt it would save many bugs changing to private because people just change the visibility themselves using :


>Furthermore, what do access attributes have to do with the order they are
>declared ? if a piece of code is designed correctly, a reader should look at
>the documentation, and never at the code.
>
Good point.

-- 
-Anderson: http://badmama.com.au/~anderson/

Achilleas Margaritis wrote:
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> news:c7ocbg$7ij$1@digitaldaemon.com...
> 
>>Achilleas Margaritis wrote:
>>
>>>From what I have seen so far, if an access attribute is omitted, then
> 
> access is
> 
>>>public. Is that on purpose or will it be fixed in later versions with
> 
> private as
> 
>>>the default access ?
>>
>>IMHO public is the correct default. Every class will have public fields,
>>but not all of them have private ones. Besides, private fields belong at
>>the end of the class definition, after the public fields, since a reader
>>of the class should not be concerned with them.
>>
>>Hauke
> 
> 
> I couldn't disagree more. Safety is the primary concern nowadays. Private
> should be the default access attribute...it is better to forget a 'private'
> than to forget a 'public': in case an access attribute is ommited, the
> public access may propagate to the final product and go unnoticed (since
> everybody would think that it has been correctly set to private). If the
> default was private, there would be no problem.

I *never*, in all my years of programming, had the problem that I accidentally forgot to make a member private that should be private. Maybe it's just my style of coding: my classes always have two parts - one public part and then one protected/private part. I know that some coders mix these freely, but, ignoring for a second the hideous mess that causes, if they do mix them then the default doesn't matter all that much anymore, since it only applies to the very first block.

> Furthermore, what do access attributes have to do with the order they are
> declared ? if a piece of code is designed correctly, a reader should look at
> the documentation, and never at the code.

They have everything to do with the order in which they are declared, since the default only applies to the first block.

Hauke

Achilleas Margaritis wrote:
> From what I have seen so far, if an access attribute is omitted, then access is
> public. Is that on purpose or will it be fixed in later versions with private as
> the default access ?

I much prefer it this way.  It makes it more natural to place the public interface at the top of the declaration. (where it belongs)

    class Foo {
        public things

    protected:
        protected things

    private:
        private stuff
    }

 -- andy

"Achilleas Margaritis" <Achilleas_member@pathlink.com> wrote in message news:c7oc2t$7d4$1@digitaldaemon.com...
> From what I have seen so far, if an access attribute is omitted, then
access is
> public. Is that on purpose or will it be fixed in later versions with
private as
> the default access ?

Good question, I'm surprised it hasn't come up before.

It's on purpose. The reason is simply that it makes it easier to write quick-and-dirty programs. Private members are for programs that are expected to live long enough to be maintained, and can afford a bit more typing for the more advanced OOP.

BTW, I write a lot of throwaway q&d programs. I like the scaffolding for more complex, carefully constructed programs, but I don't like needing all the boilerplate for q&d programs. That's one reason why printf() is built in to object.d - you don't need to import std.c.stdio to use it.

On Mon, 10 May 2004 19:00:07 +0200, Hauke Duden wrote:

> Achilleas Margaritis wrote:
>> From what I have seen so far, if an access attribute is omitted, then access is public. Is that on purpose or will it be fixed in later versions with private as the default access ?
> 
> IMHO public is the correct default. Every class will have public fields, but not all of them have private ones. Besides, private fields belong at the end of the class definition, after the public fields, since a reader of the class should not be concerned with them.
> 

I guess we are all different, eh? I try to always have every field made private and never to have any public fields. Public access to a object's data, in my code, is via public methods. D's property system is helpful to me here (not perfect but still helpful).

-- 
Derek
11/May/04 11:16:14 AM

On Mon, 10 May 2004 16:24:45 -0700, Walter wrote:

> "Achilleas Margaritis" <Achilleas_member@pathlink.com> wrote in message news:c7oc2t$7d4$1@digitaldaemon.com...
>> From what I have seen so far, if an access attribute is omitted, then
> access is
>> public. Is that on purpose or will it be fixed in later versions with
> private as
>> the default access ?
> 
> Good question, I'm surprised it hasn't come up before.
> 
> It's on purpose. The reason is simply that it makes it easier to write quick-and-dirty programs. Private members are for programs that are expected to live long enough to be maintained, and can afford a bit more typing for the more advanced OOP.
> 
> BTW, I write a lot of throwaway q&d programs. I like the scaffolding for more complex, carefully constructed programs, but I don't like needing all the boilerplate for q&d programs. That's one reason why printf() is built in to object.d - you don't need to import std.c.stdio to use it.

Now, these remarks scare more more than anything else I've heard you say, Walter.

"If something is worth doing, its worth doing well. " - to quote an old saying. It has taken me years to grow up from the 'cowboy' coding attidute to one where I now try to do things right the first time. Q&D coding is never quick and is always dirty. After many years of hard learning, I've come around to the attidute of "Goods things are not done in a hurry.". Q&D coding will eventually come back to bite the coder.

And I can't see what is so slow about coding ...

    public:

at the beginning of your q&d class definitions.

-- 
Derek
11/May/04 11:25:52 AM

Derek Parnell wrote:

>On Mon, 10 May 2004 19:00:07 +0200, Hauke Duden wrote:
>
>  
>
>>Achilleas Margaritis wrote:
>>    
>>
>>>From what I have seen so far, if an access attribute is omitted, then access is
>>>public. Is that on purpose or will it be fixed in later versions with private as
>>>the default access ?
>>>      
>>>
>>IMHO public is the correct default. Every class will have public fields, but not all of them have private ones. Besides, private fields belong at the end of the class definition, after the public fields, since a reader of the class should not be concerned with them.
>>
>>    
>>
>
>I guess we are all different, eh? I try to always have every field made
>private and never to have any public fields. Public access to a object's
>data, in my code, is via public methods. D's property system is helpful to
>me here (not perfect but still helpful).
>  
>
I used to program that way.

With D because of property methods I've found many cases where exposing properties as public is a good thing.  I mean with C++, the convention was to have get/set everywhere.  With D you can convert a property into a method without affecting the outside user (users being the people extending the class or using an instance).

I look at each properties on its own merit and try to decide if an external user would have any good use for it.  Of  course there are properties that are unsafe, have some quirky rule or ify (undecided) which I make private or protected.  They can always be made public later. I don't make everything public but I look on things from the other prospective.

-- 
-Anderson: http://badmama.com.au/~anderson/