www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Default access is public ?

reply Achilleas Margaritis <Achilleas_member pathlink.com> writes:
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 ?
May 10 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
May 10 2004
next sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"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


 public. Is that on purpose or will it be fixed in later versions with


 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.
May 10 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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
      


public. Is that on purpose or will it be fixed in later versions with
      


the default access ?
      

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.

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.

-- -Anderson: http://badmama.com.au/~anderson/
May 10 2004
prev sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
May 10 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
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
May 10 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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 ?
      

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

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/
May 10 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 11 May 2004 09:44:18 +0800, J Anderson wrote:

 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 ?
      

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

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.

I understand what you have said here. I look at it from the point of view that if I have a public field, and somebody (maybe even me) uses that in their applicaiton, and then later I change that into a private field, I can break somebody's code. By always using private fields and publics methods, I agree to the interface contract, thus minimizing my chances of inadvertantly breaking someone else's application. -- Derek 11/May/04 11:45:43 AM
May 10 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Derek Parnell wrote:

On Tue, 11 May 2004 09:44:18 +0800, J Anderson wrote:
  

        

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

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.

I understand what you have said here. I look at it from the point of view that if I have a public field, and somebody (maybe even me) uses that in their applicaiton, and then later I change that into a private field, I can break somebody's code. By always using private fields and publics methods, I agree to the interface contract, thus minimizing my chances of inadvertantly breaking someone else's application.

From my point of view I think both views are pretty much good ideas, just different ways of doing things. It's probably best to try to combine both strategies when looking at a problem and try to see the complete picture. I've come across to many libraries where you have to write of to the author to say, can you please enable this (when its obvious it should be public)... It can be frustrating. BTW: I'm a top-down programmer, mostly, so I like to see the complete abstract picture first (I generally use a UML code generation program like rational rose). -- -Anderson: http://badmama.com.au/~anderson/
May 10 2004
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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 think this is a misunderstanding. By "field" I mean methods, properties and data. And I think you will agree that a class without public "fields" in that sense is utterly useless. Hauke
May 11 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Hauke Duden wrote:

 Derek Parnell wrote:

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



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 think this is a misunderstanding. By "field" I mean methods, properties and data. And I think you will agree that a class without public "fields" in that sense is utterly useless. Hauke

There are some uses for all private classes. -- -Anderson: http://badmama.com.au/~anderson/
May 11 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 11 May 2004 11:08:34 +0200, Hauke Duden wrote:

 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 think this is a misunderstanding. By "field" I mean methods, properties and data. And I think you will agree that a class without public "fields" in that sense is utterly useless. Hauke

You're right. I misunderstood your term 'field'. I took it to mean just data elements and not to include procedural elements. Hmmm... a class that only had private elements (and thus couldn't be referenced by any other class or function) would seem a bit pointless. I'm sure somebody can come up with a (contrived?) usage for one. -- Derek 12/May/04 9:35:46 AM
May 11 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c7ro8r$27pc$1 digitaldaemon.com>, Derek Parnell says...
You're right. I misunderstood your term 'field'. I took it to mean just
data elements and not to include procedural elements.

Hmmm... a class that only had private elements (and thus couldn't be
referenced by any other class or function) would seem a bit pointless. I'm
sure somebody can come up with a (contrived?) usage for one.

-- 
Derek
12/May/04 9:35:46 AM

I guess its one way to have classes that are internal to a module, since other code in the module will not see the "private:" marker. I assume there are other D mechanisms for this, that would hide the entire class. But you may need to pass these objects around, in modules that should only understand "X *". Also: You might have a class that does something, like updating a performance counter or doing coverage analysis (ie what code is called for a given test suite), which you sprinkle over your code. It's private (er.. except the constructor, if there is one) but it's construction has side effects in a non-private global table. Kevin
May 12 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
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
May 10 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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

 public. Is that on purpose or will it be fixed in later versions with

 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.
May 10 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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

 public. Is that on purpose or will it be fixed in later versions with

 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
May 10 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Derek Parnell wrote:

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
      

public. Is that on purpose or will it be fixed in later versions with
      

the default access ?
      

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.

Now I don't know about that. Quick coding is an excellent way to write lots of test-drivers. With test-drives (and alike) you don't care about having things dogma correct.
And I can't see what is so slow about coding ...

    public:

at the beginning of your q&d class definitions.
  

-- -Anderson: http://badmama.com.au/~anderson/
May 10 2004
next sibling parent Juan C <Juan_member pathlink.com> writes:
We come into this world with all our bits in a default "public" state, and then
it's up to us to decide what we want "private". And I may add, the
better-looking the structure, the more of I want to see.  :)
May 10 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 11 May 2004 09:52:19 +0800, J Anderson wrote:

 Derek Parnell wrote:
 
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
      

public. Is that on purpose or will it be fixed in later versions with
      

the default access ?
      

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.

Now I don't know about that. Quick coding is an excellent way to write lots of test-drivers. With test-drives (and alike) you don't care about having things dogma correct.

Maybe its me then, 'cos I want my test drivers to be just as correct as the code its testing. Prototype code is throw-away code, and I can stand a fair degree of bad/poor coding practices in that sort of code.
And I can't see what is so slow about coding ...

    public:

at the beginning of your q&d class definitions.
  


Neither can I, and I never said I did. Walter said he made 'public' the default because (and I'm paraphrasing) he finds the alternative to easier to do. -- Derek 11/May/04 12:06:36 PM
May 10 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 11 May 2004 12:11:27 +1000, Derek Parnell wrote:


[snip]

 I can't see what's so slow about having private: at the start of your code.

Neither can I, and I never said I did. Walter said he made 'public' the default because (and I'm paraphrasing) he finds the alternative to easier to do.

Oooops --- that should read ... he finds the alternative *not* easier to do. -- Derek 11/May/04 12:13:02 PM
May 10 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Derek Parnell wrote:

On Tue, 11 May 2004 12:11:27 +1000, Derek Parnell wrote:


[snip]

  

I can't see what's so slow about having private: at the start of your code.
      

default because (and I'm paraphrasing) he finds the alternative to easier to do.

Oooops --- that should read ... he finds the alternative *not* easier to do.

-- -Anderson: http://badmama.com.au/~anderson/
May 10 2004
prev sibling next sibling parent Mark <mark.meuleman chello.nl> writes:
 Good question, I'm surprised it hasn't come up before.

That is: Keep asking questions! Mark
May 10 2004
prev sibling parent Achilleas Margaritis <Achilleas_member pathlink.com> writes:
In article <c7p3hc$1b1k$1 digitaldaemon.com>, Walter says...
"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

 public. Is that on purpose or will it be fixed in later versions with

 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.

I thought D was to save to world, not just you. :-) Anyway, I come from C++ and I am used to class A { public: protected: private: } But Java programmers will have a hard time to adjust.
May 11 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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 ?
  

Hehe, why not force the programmer to write both a (private or protected) and public field :). <- Sarcasm. -- -Anderson: http://badmama.com.au/~anderson/
May 11 2004