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




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




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/
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 ?
      


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/
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 ?
      


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.


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:
  


        


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.
    


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


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.



 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


 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



 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
      


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.
  


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.
  


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



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


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.
  


 
 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.
  


 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. 

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


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.

  


I guess it makes classes and structs easier to switch around.

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


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.


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