Fwd: Just curious...why "public" as default visibility ?

I think he's really talking about methods. In my mind:

public method - callers should use this and can depend upon it
protected method - extenders should use this and depend upon it
private method - not for external use; could be removed/changed/etc.
as part of refactoring, no one should use it but the class itself

private by default seems much more reasonable than any of the others;
it requires you to carefully consider what goes in your public API and
what your extension points are.

pubic by default + lazy/rushed coding == unclear intention.

At least with Java's default, lazy coding just pops out; package
private is very rarely appropriate, so it's mostly used (IME) due to
laziness. It can also be checked for with static analysis.
Public-by-default makes this impossible.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

On Mon, May 24, 2010 at 2:24 PM, Philipp Dörfler
wrote:
> Silly me - forgot to send to the list ;)
>
> ~ Philipp
>
> ---------- Forwarded message ----------
> From: Philipp Dörfler
> Date: 2010/5/24
> Subject: Re: [scala-user] Just curious...why "public" as default visibility
> ?
> To: Tobias Gierke
>
>
> Hi Tobias,
>
> I'm myself new to scala, so my points may be wrong, but nonetheless, here
> they are:
>
> In my opinion, the need for making all and every field private does not
> arise in scala as much as in Java for various reasons:
> First of all making fields private and providing accessor methods is
> something commonly found in mutable languages to ensure that the outside
> world can not change the internal state of the object. When using vals and
> immutable objects in scala, there is no way to mutate these objects from the
> outside, thus the main reason for encapsulating fields is gone.
> There are - in fact - other reasons for encapsulating fields, too: In Java,
> if you want to change the behavior of one of those accessor methods (for
> instance: getFoo()), you simply change the implementation of getFoo() and
> every access to the field "foo" from outside is affected (As long as you
> adhere to the java beans). If one would access the fields in Java directly,
> there would not be a simple way to change the methods internals that easily.
> In Scala however, the compiler generates those accessor methods (_= or =_, I
> confuse those every time...) and implementing them allows you to do the very
> same in scala, too. Without having to recompile these classes ;) So there is
> no benefit in using accessor methods in scala at all. Thus defaulting to
> public is a reasonable way to go imho.
>
> Cheers,
> ~ Philipp
>
> 2010/5/24 Tobias Gierke
>>
>> Hi,
>>
>> I think the following quote ([1]) sums it up: "The art of good
>> object-oriented design includes defining minimal, clear, and cohesive
>> public abstractions."
>>
>>
>> In my opinion, public visibility as default leads to sloppy code ( like
>> in  "uhm...typing all those "private" modifiers really wears me
>> out...I'll rather save a few keystrokes now and will stick them in
>> later"). And we all know that "later" may very well never happen. Almost
>> all Scala code examples seem to over-use default visibility ("Look ma,
>> Scala code is soooo concise !") and thus are poor examples of OO /
>> encapsulation.
>>
>>
>> Given that most code written probably is (should be) private , I wonder
>> why Scala doesn't assume "private" visibility by default ? Wouldn't this
>> make more people think about whether their
>> "doSomeTotallyInternalImplementationDependentStuff()" method really
>> needs to be public ?
>>
>> Regards,
>> Tobias
>>
>> [1] http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
>
>
>
> --
> ~ Philipp
>
>
>
> --
> ~ Philipp
>

i doubt there are lots of people who try to save time by not typing
"private" and leaving things public. in fact, i never saw one of them,
except me.
and even i made a template. i only have to type "pd", which then turns
info "private def"

David Copeland schrieb:
> I think he's really talking about methods. In my mind:
>
> public method - callers should use this and can depend upon it
> protected method - extenders should use this and depend upon it
> private method - not for external use; could be removed/changed/etc.
> as part of refactoring, no one should use it but the class itself
>
> private by default seems much more reasonable than any of the others;
> it requires you to carefully consider what goes in your public API and
> what your extension points are.
>
> pubic by default + lazy/rushed coding == unclear intention.
>
> At least with Java's default, lazy coding just pops out; package
> private is very rarely appropriate, so it's mostly used (IME) due to
> laziness. It can also be checked for with static analysis.
> Public-by-default makes this impossible.
>
> Dave
>
> ---
> My Blog: http://www.naildrivin5.com/blog
> Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
> Fork me on Github: http://davetron5000.github.com
>
>
>
>
> On Mon, May 24, 2010 at 2:24 PM, Philipp Dörfler
> wrote:
>
>> Silly me - forgot to send to the list ;)
>>
>> ~ Philipp
>>
>> ---------- Forwarded message ----------
>> From: Philipp Dörfler
>> Date: 2010/5/24
>> Subject: Re: [scala-user] Just curious...why "public" as default visibility
>> ?
>> To: Tobias Gierke
>>
>>
>> Hi Tobias,
>>
>> I'm myself new to scala, so my points may be wrong, but nonetheless, here
>> they are:
>>
>> In my opinion, the need for making all and every field private does not
>> arise in scala as much as in Java for various reasons:
>> First of all making fields private and providing accessor methods is
>> something commonly found in mutable languages to ensure that the outside
>> world can not change the internal state of the object. When using vals and
>> immutable objects in scala, there is no way to mutate these objects from the
>> outside, thus the main reason for encapsulating fields is gone.
>> There are - in fact - other reasons for encapsulating fields, too: In Java,
>> if you want to change the behavior of one of those accessor methods (for
>> instance: getFoo()), you simply change the implementation of getFoo() and
>> every access to the field "foo" from outside is affected (As long as you
>> adhere to the java beans). If one would access the fields in Java directly,
>> there would not be a simple way to change the methods internals that easily.
>> In Scala however, the compiler generates those accessor methods (_= or =_, I
>> confuse those every time...) and implementing them allows you to do the very
>> same in scala, too. Without having to recompile these classes ;) So there is
>> no benefit in using accessor methods in scala at all. Thus defaulting to
>> public is a reasonable way to go imho.
>>
>> Cheers,
>> ~ Philipp
>>
>> 2010/5/24 Tobias Gierke
>>
>>> Hi,
>>>
>>> I think the following quote ([1]) sums it up: "The art of good
>>> object-oriented design includes defining minimal, clear, and cohesive
>>> public abstractions."
>>>
>>>
>>> In my opinion, public visibility as default leads to sloppy code ( like
>>> in "uhm...typing all those "private" modifiers really wears me
>>> out...I'll rather save a few keystrokes now and will stick them in
>>> later"). And we all know that "later" may very well never happen. Almost
>>> all Scala code examples seem to over-use default visibility ("Look ma,
>>> Scala code is soooo concise !") and thus are poor examples of OO /
>>> encapsulation.
>>>
>>>
>>> Given that most code written probably is (should be) private , I wonder
>>> why Scala doesn't assume "private" visibility by default ? Wouldn't this
>>> make more people think about whether their
>>> "doSomeTotallyInternalImplementationDependentStuff()" method really
>>> needs to be public ?
>>>
>>> Regards,
>>> Tobias
>>>
>>> [1] http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
>>>
>>
>> --
>> ~ Philipp
>>
>>
>>
>> --
>> ~ Philipp
>>
>>
>
>

after all it's a choice of taste.

i am very happy the default is "public", the public modifier was getting so much on my nerves in java. also consider nested classes, usually you can just make the class itself private, then you don't need to annotate any of its methods as private any more. also note that you can define local helper methods inside a method.

also when you work a lot with traits, you will mostly have public methods there.

safes a lot of typing and improves greatly readability. thank you scala!

best, -sciss-

Am 24.05.2010 um 19:48 schrieb HamsterofDeath:

> i doubt there are lots of people who try to save time by not typing
> "private" and leaving things public. in fact, i never saw one of them,
> except me.
> and even i made a template. i only have to type "pd", which then turns
> info "private def"
>
> David Copeland schrieb:
>> I think he's really talking about methods. In my mind:
>>
>> public method - callers should use this and can depend upon it
>> protected method - extenders should use this and depend upon it
>> private method - not for external use; could be removed/changed/etc.
>> as part of refactoring, no one should use it but the class itself
>>
>> private by default seems much more reasonable than any of the others;
>> it requires you to carefully consider what goes in your public API and
>> what your extension points are.
>>
>> pubic by default + lazy/rushed coding == unclear intention.
>>
>> At least with Java's default, lazy coding just pops out; package
>> private is very rarely appropriate, so it's mostly used (IME) due to
>> laziness. It can also be checked for with static analysis.
>> Public-by-default makes this impossible.
>>
>> Dave
>>
>> ---
>> My Blog: http://www.naildrivin5.com/blog
>> Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
>> Fork me on Github: http://davetron5000.github.com
>>
>>
>>
>>
>> On Mon, May 24, 2010 at 2:24 PM, Philipp Dörfler
>> wrote:
>>
>>> Silly me - forgot to send to the list ;)
>>>
>>> ~ Philipp
>>>
>>> ---------- Forwarded message ----------
>>> From: Philipp Dörfler
>>> Date: 2010/5/24
>>> Subject: Re: [scala-user] Just curious...why "public" as default visibility
>>> ?
>>> To: Tobias Gierke
>>>
>>>
>>> Hi Tobias,
>>>
>>> I'm myself new to scala, so my points may be wrong, but nonetheless, here
>>> they are:
>>>
>>> In my opinion, the need for making all and every field private does not
>>> arise in scala as much as in Java for various reasons:
>>> First of all making fields private and providing accessor methods is
>>> something commonly found in mutable languages to ensure that the outside
>>> world can not change the internal state of the object. When using vals and
>>> immutable objects in scala, there is no way to mutate these objects from the
>>> outside, thus the main reason for encapsulating fields is gone.
>>> There are - in fact - other reasons for encapsulating fields, too: In Java,
>>> if you want to change the behavior of one of those accessor methods (for
>>> instance: getFoo()), you simply change the implementation of getFoo() and
>>> every access to the field "foo" from outside is affected (As long as you
>>> adhere to the java beans). If one would access the fields in Java directly,
>>> there would not be a simple way to change the methods internals that easily.
>>> In Scala however, the compiler generates those accessor methods (_= or =_, I
>>> confuse those every time...) and implementing them allows you to do the very
>>> same in scala, too. Without having to recompile these classes ;) So there is
>>> no benefit in using accessor methods in scala at all. Thus defaulting to
>>> public is a reasonable way to go imho.
>>>
>>> Cheers,
>>> ~ Philipp
>>>
>>> 2010/5/24 Tobias Gierke
>>>
>>>> Hi,
>>>>
>>>> I think the following quote ([1]) sums it up: "The art of good
>>>> object-oriented design includes defining minimal, clear, and cohesive
>>>> public abstractions."
>>>>
>>>>
>>>> In my opinion, public visibility as default leads to sloppy code ( like
>>>> in "uhm...typing all those "private" modifiers really wears me
>>>> out...I'll rather save a few keystrokes now and will stick them in
>>>> later"). And we all know that "later" may very well never happen. Almost
>>>> all Scala code examples seem to over-use default visibility ("Look ma,
>>>> Scala code is soooo concise !") and thus are poor examples of OO /
>>>> encapsulation.
>>>>
>>>>
>>>> Given that most code written probably is (should be) private , I wonder
>>>> why Scala doesn't assume "private" visibility by default ? Wouldn't this
>>>> make more people think about whether their
>>>> "doSomeTotallyInternalImplementationDependentStuff()" method really
>>>> needs to be public ?
>>>>
>>>> Regards,
>>>> Tobias
>>>>
>>>> [1] http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
>>>>
>>>
>>> --
>>> ~ Philipp
>>>
>>>
>>>
>>> --
>>> ~ Philipp
>>>
>>>
>>
>>
>

I think he's really talking about methods.  In my mind:

public method - callers should use this and can depend upon it
protected method - extenders should use this and depend upon it
private method - not for external use; could be removed/changed/etc.
as part of refactoring, no one should use it but the class itself

private by default seems much more reasonable than any of the others;
it requires you to carefully consider what goes in your public API and
what your extension points are.

pubic by default + lazy/rushed coding == unclear intention.

At least with Java's default, lazy coding just pops out; package
private is very rarely appropriate, so it's mostly used (IME) due to
laziness.  It can also be checked for with static analysis.
Public-by-default makes this impossible.

AANLkTimajm6PctaJQIufiR4DTcoB8VbQ07a7tnZ42V1E [at] mail [dot] gmail [dot] com" type="cite">

I think he's really talking about methods.  In my mind:
  

AANLkTimajm6PctaJQIufiR4DTcoB8VbQ07a7tnZ42V1E [at] mail [dot] gmail [dot] com" type="cite">

public method - callers should use this and can depend upon it
protected method - extenders should use this and depend upon it
private method - not for external use; could be removed/changed/etc.
as part of refactoring, no one should use it but the class itself

private by default seems much more reasonable than any of the others;
it requires you to carefully consider what goes in your public API and
what your extension points are.

pubic by default + lazy/rushed coding == unclear intention.

At least with Java's default, lazy coding just pops out; package
private is very rarely appropriate, so it's mostly used (IME) due to
laziness.  It can also be checked for with static analysis.
Public-by-default makes this impossible.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com




On Mon, May 24, 2010 at 2:24 PM, Philipp Dörfler
 wrote:
  

Silly me - forgot to send to the list ;)

~ Philipp

---------- Forwarded message ----------
From: Philipp Dörfler 
Date: 2010/5/24
Subject: Re: [scala-user] Just curious...why "public" as default visibility
?
To: Tobias Gierke 


Hi Tobias,

I'm myself new to scala, so my points may be wrong, but nonetheless, here
they are:

In my opinion, the need for making all and every field private does not
arise in scala as much as in Java for various reasons:
First of all making fields private and providing accessor methods is
something commonly found in mutable languages to ensure that the outside
world can not change the internal state of the object. When using vals and
immutable objects in scala, there is no way to mutate these objects from the
outside, thus the main reason for encapsulating fields is gone.
There are - in fact - other reasons for encapsulating fields, too: In Java,
if you want to change the behavior of one of those accessor methods (for
instance: getFoo()), you simply change the implementation of getFoo() and
every access to the field "foo" from outside is affected (As long as you
adhere to the java beans). If one would access the fields in Java directly,
there would not be a simple way to change the methods internals that easily.
In Scala however, the compiler generates those accessor methods (_= or =_, I
confuse those every time...) and implementing them allows you to do the very
same in scala, too. Without having to recompile these classes ;) So there is
no benefit in using accessor methods in scala at all. Thus defaulting to
public is a reasonable way to go imho.

Cheers,
~ Philipp

2010/5/24 Tobias Gierke 
    

Hi,

I think the following quote ([1]) sums it up: "The art of good
object-oriented design includes defining minimal, clear, and cohesive
public abstractions."

<rant on>
In my opinion, public visibility as default leads to sloppy code ( like
in  "uhm...typing all those "private" modifiers really wears me
out...I'll rather save a few keystrokes now and will stick them in
later"). And we all know that "later" may very well never happen. Almost
all Scala code examples seem to over-use default visibility ("Look ma,
Scala code is soooo concise !") and thus are poor examples of OO /
encapsulation.
</rant off>

Given that most code written probably is (should be) private , I wonder
why Scala doesn't assume "private" visibility by default ? Wouldn't this
make more people think about whether their
"doSomeTotallyInternalImplementationDependentStuff()" method really
needs to be public ?

Regards,
Tobias

[1] http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
      

--
~ Philipp



--
~ Philipp

    

If anyone here hasn't dealt with huge swaths of Java code that's all
package private because of lazy (or ignorant) coders, I am quite
envious of you.

We can't always work with top-notch people, and everyone's a newbie at
some point.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

On Mon, May 24, 2010 at 2:51 PM, Rex Kerr wrote:
> I almost completely disagree.
>
> If you want any sort of decent modular interface, you have to spend a lot of
> time thinking about how to do it right.  Typing an extra word in front of a
> few methods is a negligible increase in the amount of work you have to do.
>
> On the other hand, for rapid prototyping, you can spend most of your type
> actually typing.  Slowing that down by putting access restrictions in the
> way is foolish.
>
> private by default + lazy/rushed coding == useless package because you can't
> access what you need
> protected by default + lazy/rushed coding == useless unless you extend;
> unclear if you do
> public by default + lazy/rushed coding == unclear intention
>
> The problem is the lazy/rushed coding, not the defaults.
>
> The whole "I will make you do extra work coding just so you can demonstrate
> to me that you're not being lazy" attitude of Java is perhaps useful in some
> situations, but we already have Java for that.  I don't think adopting that
> attitude of making you do busywork would be an asset for Scala.
>
>   --Rex
>
> On Mon, May 24, 2010 at 2:42 PM, David Copeland
> wrote:
>>
>> I think he's really talking about methods.  In my mind:
>>
>> public method - callers should use this and can depend upon it
>> protected method - extenders should use this and depend upon it
>> private method - not for external use; could be removed/changed/etc.
>> as part of refactoring, no one should use it but the class itself
>>
>> private by default seems much more reasonable than any of the others;
>> it requires you to carefully consider what goes in your public API and
>> what your extension points are.
>>
>> pubic by default + lazy/rushed coding == unclear intention.
>>
>> At least with Java's default, lazy coding just pops out; package
>> private is very rarely appropriate, so it's mostly used (IME) due to
>> laziness.  It can also be checked for with static analysis.
>> Public-by-default makes this impossible.
>
>

AANLkTimYN7d9G4lPXmSqs5ESZRbyCErpZpGqAVCzvjUT [at] mail [dot] gmail [dot] com" type="cite">Silly me - forgot to send to the list ;)

~ Philipp

---------- Forwarded message ----------
From: Philipp Dörfler <phdoerfler [at] googlemail [dot] com" rel="nofollow">phdoerfler@googlemail.com>
Date: 2010/5/24
Subject: Re: [scala-user] Just curious...why "public" as default visibility ?
To: Tobias Gierke <tobias [dot] gierke [at] code-sourcery [dot] de" rel="nofollow">tobias.gierke@code-sourcery.de>


Hi Tobias,

I'm myself new to scala, so my points may be wrong, but nonetheless, here they are:

In my opinion, the need for making all and every field private does not arise in scala as much as in Java for various reasons:
First of all making fields private and providing accessor methods is something commonly found in mutable languages to ensure that the outside world can not change the internal state of the object. When using vals and immutable objects in scala, there is no way to mutate these objects from the outside, thus the main reason for encapsulating fields is gone.
There are - in fact - other reasons for encapsulating fields, too: In Java, if you want to change the behavior of one of those accessor methods (for instance: getFoo()), you simply change the implementation of getFoo() and every access to the field "foo" from outside is affected (As long as you adhere to the java beans). If one would access the fields in Java directly, there would not be a simple way to change the methods internals that easily. In Scala however, the compiler generates those accessor methods (_= or =_, I confuse those every time...) and implementing them allows you to do the very same in scala, too. Without having to recompile these classes ;) So there is no benefit in using accessor methods in scala at all. Thus defaulting to public is a reasonable way to go imho.

AANLkTimYN7d9G4lPXmSqs5ESZRbyCErpZpGqAVCzvjUT [at] mail [dot] gmail [dot] com" type="cite">
Cheers,
~ Philipp

2010/5/24 Tobias Gierke <tobias [dot] gierke [at] code-sourcery [dot] de" target="_blank" rel="nofollow">tobias.gierke@code-sourcery.de>

Hi,

I think the following quote ([1]) sums it up: "The art of good
object-oriented design includes defining minimal, clear, and cohesive
public abstractions."

<rant on>
In my opinion, public visibility as default leads to sloppy code ( like
in  "uhm...typing all those "private" modifiers really wears me
out...I'll rather save a few keystrokes now and will stick them in
later"). And we all know that "later" may very well never happen. Almost
all Scala code examples seem to over-use default visibility ("Look ma,
Scala code is soooo concise !") and thus are poor examples of OO /
encapsulation.
</rant off>

Given that most code written probably is (should be) private , I wonder
why Scala doesn't assume "private" visibility by default ? Wouldn't this
make more people think about whether their
"doSomeTotallyInternalImplementationDependentStuff()" method really
needs to be public ?

Regards,
Tobias

[1] http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules

I never would have thought that.   Would you mind sharing why private methods break encapsulation?  They've always seemed to me like a harmless way of subdividing method implementations for convenience without having break encapsulation.

On Mon, May 24, 2010 at 7:17 PM, Tony Morris <tonymorris@gmail.com> wrote:

Private methods break encapsulation.

Daniel Sobral wrote:
> Either Uncle Bob or Martin Fowler recently remarked that code which follows
> SOLID principles usually have few private methods. A private method
would be
> a code smell which is removed by SOLID refactoring.
>
> On Mon, May 24, 2010 at 5:56 PM, Clint Gilbert <
> clint_gilbert@hms.harvard.edu> wrote:
>
> It seems I'm in the minority on this one, but I'm with you.  Generally,
> I think a method should be private unless it there's a good reason to
> expose it publicly.  But maybe I'm overreacting, as I've definitely been
> bitten by too-public code.
>
> If I'm new to a codebase, or if I'm looking at my own code from a couple
> of years ago, it's often helpful to look at only the public methods of a
> class to get a quick overview of what's going on.  In effect, the access
> modifiers are a little bit of extra documentation, one that can't get
> out of sync with the code like Java/Scaladocs can.  If everything is
> public, it takes more time to figure out how the class is meant to be
> used.
>
> To those who say one shouldn't try to idiot-proof languages, I
> sympathize, but consider this: defaults that make it easier for bad
> programmers to do the right thing also help the good ones!
>
> Tobias Gierke wrote:
> >>> Hi,
> >>>
> >>> I think the following quote ([1]) sums it up: "The art of good
> >>> object-oriented design includes defining minimal, clear, and cohesive
> >>> public abstractions."
> >>>
> >>> <rant on>
> >>> In my opinion, public visibility as default leads to sloppy code (
> like
> >>> in  "uhm...typing all those "private" modifiers really wears me
> >>> out...I'll rather save a few keystrokes now and will stick them in
> >>> later"). And we all know that "later" may very well never happen.
> Almost
> >>> all Scala code examples seem to over-use default visibility ("Look ma,
> >>> Scala code is soooo concise !") and thus are poor examples of OO /
> >>> encapsulation.
> >>> </rant off>
> >>>
> >>> Given that most code written probably is (should be) private , I
> wonder
> >>> why Scala doesn't assume "private" visibility by default ?
> Wouldn't this
> >>> make more people think about whether their
> >>> "doSomeTotallyInternalImplementationDependentStuff()" method really
> >>> needs to be public ?
> >>>
> >>> Regards,
> >>> Tobias
> >>>
> >>> [1]
> http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
>>

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

My guesses...
#1because they still have to be tested (you are unit testing everything, right?)and in order to test 'private' methods you must somehow "burst the bubble"

#2because the natural units of scope are the object or the function, and encapsulation should be based on the entirety of such a scopei.e. the internals of a function are private, or one object should internally use another object (privately) "a bunch of methods that just so happen to share the same modifier" is a lousy basis for scoping/encapsulation




On 25 May 2010 00:28, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

I never would have thought that.   Would you mind sharing why private methods break encapsulation?  They've always seemed to me like a harmless way of subdividing method implementations for convenience without having break encapsulation.

On Mon, May 24, 2010 at 7:17 PM, Tony Morris <tonymorris@gmail.com> wrote:

Private methods break encapsulation.

Daniel Sobral wrote:
> Either Uncle Bob or Martin Fowler recently remarked that code which follows
> SOLID principles usually have few private methods. A private method
would be
> a code smell which is removed by SOLID refactoring.
>
> On Mon, May 24, 2010 at 5:56 PM, Clint Gilbert <
> clint_gilbert@hms.harvard.edu> wrote:
>
> It seems I'm in the minority on this one, but I'm with you.  Generally,
> I think a method should be private unless it there's a good reason to
> expose it publicly.  But maybe I'm overreacting, as I've definitely been
> bitten by too-public code.
>
> If I'm new to a codebase, or if I'm looking at my own code from a couple
> of years ago, it's often helpful to look at only the public methods of a
> class to get a quick overview of what's going on.  In effect, the access
> modifiers are a little bit of extra documentation, one that can't get
> out of sync with the code like Java/Scaladocs can.  If everything is
> public, it takes more time to figure out how the class is meant to be
> used.
>
> To those who say one shouldn't try to idiot-proof languages, I
> sympathize, but consider this: defaults that make it easier for bad
> programmers to do the right thing also help the good ones!
>
> Tobias Gierke wrote:
> >>> Hi,
> >>>
> >>> I think the following quote ([1]) sums it up: "The art of good
> >>> object-oriented design includes defining minimal, clear, and cohesive
> >>> public abstractions."
> >>>
> >>> <rant on>
> >>> In my opinion, public visibility as default leads to sloppy code (
> like
> >>> in  "uhm...typing all those "private" modifiers really wears me
> >>> out...I'll rather save a few keystrokes now and will stick them in
> >>> later"). And we all know that "later" may very well never happen.
> Almost
> >>> all Scala code examples seem to over-use default visibility ("Look ma,
> >>> Scala code is soooo concise !") and thus are poor examples of OO /
> >>> encapsulation.
> >>> </rant off>
> >>>
> >>> Given that most code written probably is (should be) private , I
> wonder
> >>> why Scala doesn't assume "private" visibility by default ?
> Wouldn't this
> >>> make more people think about whether their
> >>> "doSomeTotallyInternalImplementationDependentStuff()" method really
> >>> needs to be public ?
> >>>
> >>> Regards,
> >>> Tobias
> >>>
> >>> [1]
> http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
>>

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

I still don't see how private methods break encapsulation. Perhaps one can argue that they over-encapsulate, but that is a different matter. Am I missing something?

Also, I don't understand the objection to private methods. If several public methods each need some significant functionality that is common to all of them, shouldn't that functionality be factored out as a private method rather than repeated for each case?

Russ P.

On Mon, May 24, 2010 at 4:36 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

My guesses...
#1because they still have to be tested (you are unit testing everything, right?)and in order to test 'private' methods you must somehow "burst the bubble"

#2because the natural units of scope are the object or the function, and encapsulation should be based on the entirety of such a scopei.e. the internals of a function are private, or one object should internally use another object (privately) "a bunch of methods that just so happen to share the same modifier" is a lousy basis for scoping/encapsulation




On 25 May 2010 00:28, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

I never would have thought that.   Would you mind sharing why private methods break encapsulation?  They've always seemed to me like a harmless way of subdividing method implementations for convenience without having break encapsulation.

On Mon, May 24, 2010 at 7:17 PM, Tony Morris <tonymorris@gmail.com> wrote:

Private methods break encapsulation.

Daniel Sobral wrote:
> Either Uncle Bob or Martin Fowler recently remarked that code which follows
> SOLID principles usually have few private methods. A private method
would be
> a code smell which is removed by SOLID refactoring.
>
> On Mon, May 24, 2010 at 5:56 PM, Clint Gilbert <
> clint_gilbert@hms.harvard.edu> wrote:
>
> It seems I'm in the minority on this one, but I'm with you.  Generally,
> I think a method should be private unless it there's a good reason to
> expose it publicly.  But maybe I'm overreacting, as I've definitely been
> bitten by too-public code.
>
> If I'm new to a codebase, or if I'm looking at my own code from a couple
> of years ago, it's often helpful to look at only the public methods of a
> class to get a quick overview of what's going on.  In effect, the access
> modifiers are a little bit of extra documentation, one that can't get
> out of sync with the code like Java/Scaladocs can.  If everything is
> public, it takes more time to figure out how the class is meant to be
> used.
>
> To those who say one shouldn't try to idiot-proof languages, I
> sympathize, but consider this: defaults that make it easier for bad
> programmers to do the right thing also help the good ones!
>
> Tobias Gierke wrote:
> >>> Hi,
> >>>
> >>> I think the following quote ([1]) sums it up: "The art of good
> >>> object-oriented design includes defining minimal, clear, and cohesive
> >>> public abstractions."
> >>>
> >>> <rant on>
> >>> In my opinion, public visibility as default leads to sloppy code (
> like
> >>> in  "uhm...typing all those "private" modifiers really wears me
> >>> out...I'll rather save a few keystrokes now and will stick them in
> >>> later"). And we all know that "later" may very well never happen.
> Almost
> >>> all Scala code examples seem to over-use default visibility ("Look ma,
> >>> Scala code is soooo concise !") and thus are poor examples of OO /
> >>> encapsulation.
> >>> </rant off>
> >>>
> >>> Given that most code written probably is (should be) private , I
> wonder
> >>> why Scala doesn't assume "private" visibility by default ?
> Wouldn't this
> >>> make more people think about whether their
> >>> "doSomeTotallyInternalImplementationDependentStuff()" method really
> >>> needs to be public ?
> >>>
> >>> Regards,
> >>> Tobias
> >>>
> >>> [1]
> http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
>>

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

On Tuesday May 25 2010, Kevin Wright wrote:
> My design sense nowadays is leaning towards:
>
> - If that "significant functionality" is a core competency of the
> class, then it can be public
> - If it's not, then it can be factored into another class where it IS
> a core competency, and be made public

Just for the sake of not having a private method? That's spurious.

Randall Schulz

On Tuesday May 25 2010, Kevin Wright wrote:
> My design sense nowadays is leaning towards:
>
> - If that "significant functionality" is a core competency of the
> class, then it can be public
> - If it's not, then it can be factored into another class where it IS
> a core competency, and be made public

Just for the sake of not having a private method? That's spurious.


Randall Schulz

One thing to consider is that if you created a private method by
extracting it from a well-tested public/protected method (i.e. as part
of the third "refactor" step of TDD), keeping it private means you do
not need to write additional tests; if you then break that private
method out into its own class that your original class uses, you
really need to create tests specific for this new class (as it is now
public). You may not have the time, nor desire, to do this.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

On Wed, May 26, 2010 at 3:59 AM, Kevin Wright
wrote:
> I'm not saying that private methods don't have a place, and should be
> avoided at all costs.
> In my experience though, if you're tempted to make a method private then you
> should first consider:
> a. will this method *truly* never be used outside the class?
> b. does the extra testing pain really justify the marginally cleaner
> interface?
> c. If this method is used internally from multiple places then is it really
> defined on the right object?
> It's also very telling that TDD/BDD approaches seem to produce less private
> code in the first place.
> and don't forget that if clients only use your object via an interface, then
> public/private doesn't make that much difference to them (unless they cast
> to the concrete type).  It does however have an impact on testing/debugging.
>
>
> On 26 May 2010 00:14, Randall R Schulz wrote:
>>
>> On Tuesday May 25 2010, Kevin Wright wrote:
>> > My design sense nowadays is leaning towards:
>> >
>> > - If that "significant functionality" is a core competency of the
>> > class, then it can be public
>> > - If it's not, then it can be factored into another class where it IS
>> > a core competency, and be made public
>>
>> Just for the sake of not having a private method? That's spurious.
>>
>>
>> Randall Schulz
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>
>

One thing to consider is that if you created a private method by
extracting it from a well-tested public/protected method (i.e. as part
of the third "refactor" step of TDD), keeping it private means you do
not need to write additional tests; if you then break that private
method out into its own class that your original class uses, you
really need to create tests specific for this new class (as it is now
public).  You may not have the time, nor desire, to do this.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com




On Wed, May 26, 2010 at 3:59 AM, Kevin Wright
<kev.lee.wright@googlemail.com> wrote:
> I'm not saying that private methods don't have a place, and should be
> avoided at all costs.
> In my experience though, if you're tempted to make a method private then you
> should first consider:
> a. will this method *truly* never be used outside the class?
> b. does the extra testing pain really justify the marginally cleaner
> interface?
> c. If this method is used internally from multiple places then is it really
> defined on the right object?
> It's also very telling that TDD/BDD approaches seem to produce less private
> code in the first place.
> and don't forget that if clients only use your object via an interface, then
> public/private doesn't make that much difference to them (unless they cast
> to the concrete type).  It does however have an impact on testing/debugging.
>
>
> On 26 May 2010 00:14, Randall R Schulz <rschulz@sonic.net> wrote:
>>
>> On Tuesday May 25 2010, Kevin Wright wrote:
>> > My design sense nowadays is leaning towards:
>> >
>> > - If that "significant functionality" is a core competency of the
>> > class, then it can be public
>> > - If it's not, then it can be factored into another class where it IS
>> > a core competency, and be made public
>>
>> Just for the sake of not having a private method? That's spurious.
>>
>>
>> Randall Schulz
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>
>

Big long religious discussion. Having been to hell and back in the
past 2 decades, will give away my 3c.

1c. I use private only to inform reader/user not to worry/read about
that field/method
2c don't assume users of your thing are morons and try to protect them
from harm. They are at least as smart as you are...if not smarter...
for NOT having written your thing but rather reusing it :)
3c. Use protected, if you must hide something.

I have noticed a strong correlation between the amount of code
"hidden" and the overall quality of code. The more hidden, the worse
it is, brittle and untested.

If I am to hide something, I normally do that via
interface/implementation. I "hide" the entire implementation in plain
sight, in embedded packages.

Cheers

P.S. In scala, specifically, default publicity makes sense from many
points of view, among which: preferred immutability, ease of
refactoring access etc
The general principle behind scala I think is "practicality" which
really is unexpected coming from an european :). Java is really a
confused language, starting on mobile phones and coffe makers and
moving on to the Enterprise and the internet.
The JVM was the really interesting bit always, the language itself is
just a shell: a bunch of conventions and a compiler.

On 5/26/10, Kevin Wright wrote:
> I'm not saying that private methods don't have a place, and should be
> avoided at all costs.
> In my experience though, if you're tempted to make a method private then you
> should first consider:
>
> a. will this method *truly* never be used outside the class?
> b. does the extra testing pain really justify the marginally cleaner
> interface?
> c. If this method is used internally from multiple places then is it really
> defined on the right object?
>
> It's also very telling that TDD/BDD approaches seem to produce less private
> code in the first place.
>
> and don't forget that if clients only use your object via an interface, then
> public/private doesn't make that much difference to them (unless they cast
> to the concrete type). It does however have an impact on testing/debugging.
>
>
>
> On 26 May 2010 00:14, Randall R Schulz wrote:
>
>> On Tuesday May 25 2010, Kevin Wright wrote:
>> > My design sense nowadays is leaning towards:
>> >
>> > - If that "significant functionality" is a core competency of the
>> > class, then it can be public
>> > - If it's not, then it can be factored into another class where it IS
>> > a core competency, and be made public
>>
>> Just for the sake of not having a private method? That's spurious.
>>
>>
>> Randall Schulz
>>
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>

My guesses...
#1because they still have to be tested (you are unit testing everything, right?)and in order to test 'private' methods you must somehow "burst the bubble"

#2because the natural units of scope are the object or the function, and encapsulation should be based on the entirety of such a scope i.e. the internals of a function are private, or one object should internally use another object (privately) "a bunch of methods that just so happen to share the same modifier" is a lousy basis for scoping/encapsulation

On 25 May 2010 00:28, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

I never would have thought that.   Would you mind sharing why private methods break encapsulation?  They've always seemed to me like a harmless way of subdividing method implementations for convenience without having break encapsulation.

On Mon, May 24, 2010 at 7:17 PM, Tony Morris <tonymorris@gmail.com> wrote:

Private methods break encapsulation.

Daniel Sobral wrote:
> Either Uncle Bob or Martin Fowler recently remarked that code which follows
> SOLID principles usually have few private methods. A private method
would be
> a code smell which is removed by SOLID refactoring.
>
> On Mon, May 24, 2010 at 5:56 PM, Clint Gilbert <
> clint_gilbert@hms.harvard.edu> wrote:
>
> It seems I'm in the minority on this one, but I'm with you.  Generally,
> I think a method should be private unless it there's a good reason to
> expose it publicly.  But maybe I'm overreacting, as I've definitely been
> bitten by too-public code.
>
> If I'm new to a codebase, or if I'm looking at my own code from a couple
> of years ago, it's often helpful to look at only the public methods of a
> class to get a quick overview of what's going on.  In effect, the access
> modifiers are a little bit of extra documentation, one that can't get
> out of sync with the code like Java/Scaladocs can.  If everything is
> public, it takes more time to figure out how the class is meant to be
> used.
>
> To those who say one shouldn't try to idiot-proof languages, I
> sympathize, but consider this: defaults that make it easier for bad
> programmers to do the right thing also help the good ones!
>
> Tobias Gierke wrote:
> >>> Hi,
> >>>
> >>> I think the following quote ([1]) sums it up: "The art of good
> >>> object-oriented design includes defining minimal, clear, and cohesive
> >>> public abstractions."
> >>>
> >>> <rant on>
> >>> In my opinion, public visibility as default leads to sloppy code (
> like
> >>> in  "uhm...typing all those "private" modifiers really wears me
> >>> out...I'll rather save a few keystrokes now and will stick them in
> >>> later"). And we all know that "later" may very well never happen.
> Almost
> >>> all Scala code examples seem to over-use default visibility ("Look ma,
> >>> Scala code is soooo concise !") and thus are poor examples of OO /
> >>> encapsulation.
> >>> </rant off>
> >>>
> >>> Given that most code written probably is (should be) private , I
> wonder
> >>> why Scala doesn't assume "private" visibility by default ?
> Wouldn't this
> >>> make more people think about whether their
> >>> "doSomeTotallyInternalImplementationDependentStuff()" method really
> >>> needs to be public ?
> >>>
> >>> Regards,
> >>> Tobias
> >>>
> >>> [1]
> http://programming-scala.labs.oreilly.com/ch05.html#VisibilityRules
>>

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Mon, May 24, 2010 at 4:36 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

My guesses...
#1because they still have to be tested (you are unit testing everything, right?)and in order to test 'private' methods you must somehow "burst the bubble"

Say I have several public methods that each need the same few lines of code executed. That's not uncommon. The right thing to do, it seems to me (in some cases at least), is to factor out those common lines and make them a private (or protected) method. Then the overall code is cleaner, any change to that code needs to be made in only one place, and consistency is easier to maintain.

Now, you claim that the private function is inaccessible for testing. Why? First of all, temporarily removing the "private" declaration for testing is simple enough, if necessary. But more importantly, when you test the public methods that use it, you are testing the private method exactly as if you had left in inline in several places. You are doing no less testing than before you defined the private method!


 

#2because the natural units of scope are the object or the function, and encapsulation should be based on the entirety of such a scope i.e. the internals of a function are private, or one object should internally use another object (privately) "a bunch of methods that just so happen to share the same modifier" is a lousy basis for scoping/encapsulation

You lost me here.

Russ P.

On 25 May 2010 00:28, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

I never would have thought that.   Would you mind sharing why private methods break encapsulation?  They've always seemed to me like a harmless way of subdividing method implementations for convenience without having break encapsulation.

On Mon, May 24, 2010 at 7:17 PM, Tony Morris <tonymorris@gmail.com> wrote:

Private methods break encapsulation.

I think that
  private def x
breaks encapsulation in a way that
  private[this] def x
does not.

The reason is that I can
  def op(them: SameClassAsMe) = them.x
which means that I am saying that x is an implementation detail, yet I get to fiddle with it in objects that are not me.

This is very useful in some cases, admittedly, but it is a sort of violation of the encapsulation you're trying to achieve by marking something "private".  Now, if you decide to change things--to allow inheritance, for example--you have a mess, because you can no longer assume that their x works the same way as yours.  So the private->protected conversion becomes a non-trivial refactor precisely because you've given yourself authorization to break the encapsulation that you insist that everyone else must obey.

Big long religious discussion. Having been to hell and back in the
past 2 decades, will give away my 3c.

1c. I use private only to inform reader/user not to worry/read about
that field/method
2c don't assume users of your thing are morons and try to protect them
from harm. They are at least as smart as you are...if not smarter...
for NOT having written your thing but rather reusing it :)
3c. Use protected, if you must hide something.

I have noticed a strong correlation between the amount of code
"hidden" and the overall quality of code. The more hidden, the worse
it is, brittle and untested.

If I am to hide something, I normally do that via
interface/implementation. I "hide" the entire implementation in plain
sight, in embedded packages.

Cheers

On Wed, May 26, 2010 at 3:10 PM, Rex Kerr <ichoran@gmail.com> wrote:

I think that
  private def x
breaks encapsulation in a way that
  private[this] def x
does not.

The reason is that I can
  def op(them: SameClassAsMe) = them.x
which means that I am saying that x is an implementation detail, yet I get to fiddle with it in objects that are not me.

Doesn't the same concern apply to public methods?

So is the objection here that the "private" modifier is misleading, or is it that your are worse off than if you had simply omitted it and let the definition default to public?

…indeed, makes the most sense, for all our assumptions above J

So it’s regularity then, followed by practicality? Or practicality just flows from keeping the rules simple and unified?

From: odersky@gmail.com [mailto:odersky@gmail.com] On Behalf Of martin odersky
Sent: Thursday, May 27, 2010 6:38 AM
To: Razie
Cc: scala-user@listes.epfl.ch
Subject: Re: [scala-user] Just curious...why "public" as default visibility ?

On Wed, May 26, 2010 at 4:59 PM, Razie <razvanc99@gmail.com> wrote:

Big long religious discussion. Having been to hell and back in the
past 2 decades, will give away my 3c.

1c. I use private only to inform reader/user not to worry/read about
that field/method
2c don't assume users of your thing are morons and try to protect them
from harm. They are at least as smart as you are...if not smarter...
for NOT having written your thing but rather reusing it :)
3c. Use protected, if you must hide something.

I have noticed a strong correlation between the amount of code
"hidden" and the overall quality of code. The more hidden, the worse
it is, brittle and untested.

If I am to hide something, I normally do that via
interface/implementation. I "hide" the entire implementation in plain
sight, in embedded packages.

Cheers

The main reason to make public the default were traits. Note that in Java interface methods are also public by default, and that for good reason, because adding public to every interface method would be 100% redundant. Since in Scala traits occupy a middle ground between classes and interfaces, there was no good borderline between them and classes. So we went public for all members.

In the end it comes down to a choice between SW engineering principles baked into a language (and you can argue about those) and language regularity (about which you cannot argue -- it's regular or isn't). Scala has chosen regularity.

Cheers

 -- Martin
 

On Thu, May 27, 2010 at 1:14 AM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Wed, May 26, 2010 at 3:10 PM, Rex Kerr <ichoran@gmail.com> wrote:

I think that
  private def x
breaks encapsulation in a way that
  private[this] def x
does not.

The reason is that I can
  def op(them: SameClassAsMe) = them.x
which means that I am saying that x is an implementation detail, yet I get to fiddle with it in objects that are not me.

Doesn't the same concern apply to public methods?

So is the objection here that the "private" modifier is misleading, or is it that your are worse off than if you had simply omitted it and let the definition default to public?

The objection is that the private modifier specifies something strange with regard to encapsulation--it is asserting, basically, that the wisdom of the coder is such that he or she can think correctly about the interactions between objects of a certain class (including fiddling with their internals), but that others cannot.

Sometimes this is true; sometimes the coder only thinks this is true; sometimes the decision needs to be changed and it is non-obvious how things break when the assumption is violated.

My objection is that if it really is an (perhaps code-saving) implementation detail, private[this] is often a better choice, because it insists that you only have to reason about one copy of the class (the "this" copy), not an arbitrary number of them simultaneously.  If it is a detail that involves interactions between objects, even if you do want to hide the details from a casual user, maybe protected or protected[package] is the more sensible marking.

In some cases, e.g. when trying to strike a balance between performance and ease of use, it is valuable to hide implementation details while nonetheless handling multiple instances at once.  But I think the common OOP idea that "making it private makes it safely encapsulated" can be misleading.  The modifier itself isn't misleading as long as you know what the consequences are.

  --Rex

I think trying to guess the intent behind comment that private members break encapsulation is pointless. If the person who made the comment wanted you to understand it, he'd have explained it.

On Wed, Jun 2, 2010 at 2:39 PM, Rex Kerr wrote:
> Here, by relying upon a private method, Parent has created a situation where
> Child doesn't behave the way it ought to--because Child can't override that
> private method with something sensible, and Parent assumed that it was so
> clever that it could use an internal method instead of part of the public
> interface.  If parent restricted itself to private[this], it wouldn't be a
> problem.

extension is hard?

"The discussion above suggests that developers should avoid calling
public methods on the current object this."

http://www.cs.cmu.edu/~aldrich/papers/savcbs04.pdf