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/

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/

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

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