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

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/

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/

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

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

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

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

That is: Keep asking questions!

Mark

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/

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

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.