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

On Mon, May 24, 2010 at 1:02 PM, Tobias Gierke <tobias.gierke@code-sourcery.de> wrote:

and thus are poor examples of OO / encapsulation.

It's worth noting that all fields in Scala are private. Always. Cannot be made public. So technically, encapsulation is preserved.

Much of the necessesity for encapsulation comes from controlling effects, especially mutating data.  The object must keep itself in a consistent state!  But if the object is stateless, there's no consistent state to be preserved.   So if you use a predominatly functional style the need for strict encapsulation diminishes substantially.  I'd say enough to warrant public-by-default.

On Mon, May 24, 2010 at 2:02 PM, Tobias Gierke <tobias.gierke@code-sourcery.de> 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

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

how should i put it: if it can be changed from outside, it is public.

Nils Kilden-Pedersen schrieb:
> On Mon, May 24, 2010 at 1:02 PM, Tobias Gierke
> > wrote:
>
> and thus are poor examples of OO / encapsulation.
>
>
> It's worth noting that all fields in Scala are private. Always. Cannot
> be made public. So technically, encapsulation is preserved.

Hi,

AANLkTinWYV_UFBCCFV459I78KUf2ubrKRPjMXu5HM6YE [at] mail [dot] gmail [dot] com" type="cite"> Much of the necessesity for encapsulation comes from controlling effects, especially mutating data.  The object must keep itself in a consistent state!  But if the object is stateless, there's no consistent state to be preserved.   So if you use a predominatly functional style the need for strict encapsulation diminishes substantially.  I'd say enough to warrant public-by-default.

I tend to disagree. Besides the obvious use-case (encapsulation) , to me visibility modifiers also express an intent ( like "This is part of a public API and I'm aware of this and will try to not break your stuff"). By having only public methods , all those methods could potentially be used by client code and therefore are more or less unchangeable once my code has been released.

Tobias

AANLkTinWYV_UFBCCFV459I78KUf2ubrKRPjMXu5HM6YE [at] mail [dot] gmail [dot] com" type="cite"> On Mon, May 24, 2010 at 2:02 PM, Tobias Gierke <tobias [dot] gierke [at] code-sourcery [dot] de" rel="nofollow">tobias.gierke@code-sourcery.de> 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

Hi,

what's worse than typing access modifiers, to me, is reading them. No matter if it's public, protected, private or whatnot, it just clutters the code a lot. A few weeks ago, there was "a modest proposal" or so (IIRC) on this list to use something like the "public:", "private:" switches known from C++ (uh oh, I know...).

Something to switch the "default" access modifier applied (from a point downwards the sourcefile), would probably be handy. Though there are more urgent matters right now, imho.

Just my 2c
Andreas

Am 24.05.2010 um 20:02 schrieb 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
>

oh, i missed that. how can i cast my vote? i'd love that one... i never understood why java needed to put have them in front of every method. it also separates the code better.

Am 24.05.2010 um 20:11 schrieb Andreas Flierl:

> A few weeks ago, there was "a modest proposal" or so (IIRC) on this list to use something like the "public:", "private:" switches known from C++ (uh oh, I know...).

Why should those of us who do a lot of exploratory work, or work on disciplined teams where people can be trusted to rationally consider access qualifiers on their interfaces, be punished because some people can't be bothered to type a few characters, much less actually think about it?   There's a big difference between "if you call this method with the wrong stuff or in the wrong sequence the object is going to mutate, die a horrible death, and possibly take your whole system with it" versus "I may change this method later and break your code, so don't call it."   Compensating for programmer idiocy is a losing battle.  There's no point in designing a language around the idea.
On Mon, May 24, 2010 at 3:15 PM, Tobias Gierke <tobias.gierke@code-sourcery.de> wrote:

Hi,

Much of the necessesity for encapsulation comes from controlling effects, especially mutating data.  The object must keep itself in a consistent state!  But if the object is stateless, there's no consistent state to be preserved.   So if you use a predominatly functional style the need for strict encapsulation diminishes substantially.  I'd say enough to warrant public-by-default.

I tend to disagree. Besides the obvious use-case (encapsulation) , to me visibility modifiers also express an intent ( like "This is part of a public API and I'm aware of this and will try to not break your stuff"). By having only public methods , all those methods could potentially be used by client code and therefore are more or less unchangeable once my code has been released.

Tobias

On Mon, May 24, 2010 at 2:02 PM, Tobias Gierke <tobias.gierke@code-sourcery.de> 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

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

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

Hi Erik,

AANLkTinypHD4lvYt1fd8YLSUoZ_GN5_W87dnT8gP6b_o [at] mail [dot] gmail [dot] com" type="cite"> Why should those of us who do a lot of exploratory work, or work on disciplined teams where people can be trusted to rationally consider access qualifiers on their interfaces, be punished because some people can't be bothered to type a few characters, much less actually think about it?

While the current majority of Scala programmers are excellent , this unfortunately cannot be said about the majority of programmers overall (at least from my experience,YMMV).

AANLkTinypHD4lvYt1fd8YLSUoZ_GN5_W87dnT8gP6b_o [at] mail [dot] gmail [dot] com" type="cite">   There's a big difference between "if you call this method with the wrong stuff or in the wrong sequence the object is going to mutate, die a horrible death, and possibly take your whole system with it" versus "I may change this method later and break your code, so don't call it."   Compensating for programmer idiocy is a losing battle.  There's no point in designing a language around the idea.

Point taken. Maybe I'm overprotective but I think about this more as a case of "don't shoot yourself in the foot". Then again, maybe everyone has to feel the pain ;)

Regards,
Tobias

AANLkTinypHD4lvYt1fd8YLSUoZ_GN5_W87dnT8gP6b_o [at] mail [dot] gmail [dot] com" type="cite"> On Mon, May 24, 2010 at 3:15 PM, Tobias Gierke <tobias [dot] gierke [at] code-sourcery [dot] de" rel="nofollow">tobias.gierke@code-sourcery.de> wrote:

Hi,

Much of the necessesity for encapsulation comes from controlling effects, especially mutating data.  The object must keep itself in a consistent state!  But if the object is stateless, there's no consistent state to be preserved.   So if you use a predominatly functional style the need for strict encapsulation diminishes substantially.  I'd say enough to warrant public-by-default.

I tend to disagree. Besides the obvious use-case (encapsulation) , to me visibility modifiers also express an intent ( like "This is part of a public API and I'm aware of this and will try to not break your stuff"). By having only public methods , all those methods could potentially be used by client code and therefore are more or less unchangeable once my code has been released.

Tobias

On Mon, May 24, 2010 at 2:02 PM, Tobias Gierke <tobias [dot] gierke [at] code-sourcery [dot] de" target="_blank" rel="nofollow">tobias.gierke@code-sourcery.de> 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

i also suggest looking at real code.

i just picked randomly my audio file class (including related traits etc.):

public methods / fields 49
public objects / classes / traits 2
private methods / fields 5
protected methods / fields 8
private inner objects / classes / traits : 9

and this has been very carefully designed, all the visibility is correct. this is just the main class, there are more objects with the same statistics.

now you don't even need to start counting to see why "def" as public makes so much more sense than java's way. it's much less typing, and much better readability.

best, -sciss-

Am 24.05.2010 um 20:38 schrieb Erik Engbrecht:

> Why should those of us who do a lot of exploratory work, or work on disciplined teams where people can be trusted to rationally consider access qualifiers on their interfaces, be punished because some people can't be bothered to type a few characters, much less actually think about it?
>
> There's a big difference between "if you call this method with the wrong stuff or in the wrong sequence the object is going to mutate, die a horrible death, and possibly take your whole system with it" versus "I may change this method later and break your code, so don't call it."
>
> Compensating for programmer idiocy is a losing battle. There's no point in designing a language around the idea.
> On Mon, May 24, 2010 at 3:15 PM, Tobias Gierke wrote:
> Hi,
>> Much of the necessesity for encapsulation comes from controlling effects, especially mutating data. The object must keep itself in a consistent state! But if the object is stateless, there's no consistent state to be preserved.
>>
>> So if you use a predominatly functional style the need for strict encapsulation diminishes substantially. I'd say enough to warrant public-by-default.
> I tend to disagree. Besides the obvious use-case (encapsulation) , to me visibility modifiers also express an intent ( like "This is part of a public API and I'm aware of this and will try to not break your stuff"). By having only public methods , all those methods could potentially be used by client code and therefore are more or less unchangeable once my code has been released.
>
> Tobias
>
>
>> On Mon, May 24, 2010 at 2:02 PM, 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."
>>
>>
>> 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
>>
>>
>>

Not really. Encapsulation is about protecting internal state, not whether the public interface happens to correlate. Given this interface, tell me how the internal state is stored?
class Foo {
  def bar(): String
}

As a String? You have no way to know, nor should you care. Encapsulation is preserved.

On Mon, May 24, 2010 at 1:23 PM, HamsterofDeath <h-star@gmx.de> wrote:

how should i put it: if it can be changed from outside, it is public.


Nils Kilden-Pedersen schrieb:
> On Mon, May 24, 2010 at 1:02 PM, Tobias Gierke
> <tobias.gierke@code-sourcery.de
> <mailto:tobias.gierke@code-sourcery.de>> wrote:
>
>     and thus are poor examples of OO / encapsulation.
>
>
> It's worth noting that all fields in Scala are private. Always. Cannot
> be made public. So technically, encapsulation is preserved.

Hi,

7CC03056-4EEA-4756-B7C5-114353C38D9D [at] sciss [dot] de" type="cite">

i also suggest looking at real code.

i just picked randomly my audio file class (including related traits etc.):

public methods / fields 49
public objects / classes / traits 2
private methods / fields 5
protected methods / fields 8
private inner objects / classes / traits : 9

and this has been very carefully designed, all the visibility is correct. this is just the main class, there are more objects with the same statistics.

now you don't even need to start counting to see why "def" as public makes so much more sense than java's way. it's much less typing, and much better readability.
  

You're right. I just ran again a check against some of my own code (method declarations only) , and the majority is in fact ... public. Hmpf, somehow I had the feeling there were more private/protected than public ones. So Scala clearly wins in the "less keystrokes, more readability" department - and in the "with great power comes great responsibility" department as well ;)

Thanks,
Tobias

7CC03056-4EEA-4756-B7C5-114353C38D9D [at] sciss [dot] de" type="cite">

best, -sciss-



Am 24.05.2010 um 20:38 schrieb Erik Engbrecht:

  

Why should those of us who do a lot of exploratory work, or work on disciplined teams where people can be trusted to rationally consider access qualifiers on their interfaces, be punished because some people can't be bothered to type a few characters, much less actually think about it?
 
There's a big difference between "if you call this method with the wrong stuff or in the wrong sequence the object is going to mutate, die a horrible death, and possibly take your whole system with it" versus "I may change this method later and break your code, so don't call it."
 
Compensating for programmer idiocy is a losing battle.  There's no point in designing a language around the idea.
On Mon, May 24, 2010 at 3:15 PM, Tobias Gierke  wrote:
Hi,
    

Much of the necessesity for encapsulation comes from controlling effects, especially mutating data.  The object must keep itself in a consistent state!  But if the object is stateless, there's no consistent state to be preserved.
 
So if you use a predominatly functional style the need for strict encapsulation diminishes substantially.  I'd say enough to warrant public-by-default.
      

I tend to disagree. Besides the obvious use-case (encapsulation) , to me visibility modifiers also express an intent ( like "This is part of a public API and I'm aware of this and will try to not break your stuff"). By having only public methods , all those methods could potentially be used by client code and therefore are more or less unchangeable once my code has been released.

Tobias


    

On Mon, May 24, 2010 at 2:02 PM, 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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv65+cACgkQ5IyIbnMUeTv37wCePw8ZfgqX67GAgeiNkzBc57BH
EpUAn2rbBS6uXO7gleo7rlzdFQsiLIt6
=fjpz
-----END PGP SIGNATURE-----

So all private fields in Java for which there are setters are public? That's non-sense. Besides, you shouldn't use var anyway.

On Mon, May 24, 2010 at 3:23 PM, HamsterofDeath <h-star@gmx.de> wrote:

how should i put it: if it can be changed from outside, it is public.


Nils Kilden-Pedersen schrieb:
> On Mon, May 24, 2010 at 1:02 PM, Tobias Gierke
> <tobias.gierke@code-sourcery.de
> <mailto:tobias.gierke@code-sourcery.de>> wrote:
>
>     and thus are poor examples of OO / encapsulation.
>
>
> It's worth noting that all fields in Scala are private. Always. Cannot
> be made public. So technically, encapsulation is preserved.

--
Daniel C. Sobral

I travel to the future all the time.

// version 1class Point(val x: Double, val y: Double)
// version 2class Point(x0: Double y0: Double) {  private val r = math.sqrt(x0*x0 + y0*y0)  private val theta = math.atan2(x0, y0)
  def x = r * math.cos(theta)  def y = r * math.sin(theta)}
So, here's the thing... in both examples, "x" and "y" are getter methods. The true fields are private and hidden, so I could change it in version 2 and no one would be bothered, because no one could ever have access to it. Mind you, the "private val" also defines getters (but, iirc, Scala actually compiles access to that as direct field access).

On Mon, May 24, 2010 at 3:02 PM, Tobias Gierke <tobias.gierke@code-sourcery.de> 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

--
Daniel C. Sobral

I travel to the future all the time.

Just for fun, I did the same thing on the (Java) project I'm working on:

total # of classes: 168
public methods: 572 (3.4 per class)
private methods: 487 (2.8 per class)
protected methods: 100 (.6 per class)

For non-library code, this feels about right to me, though I was
expecting more private methods. A class with 49 public methods smells
like a god object to me.

For Spring 2.5.6 (1676 classes):

public methods: 9780 (5.83 per class)
private methods: 3775 (2.25 per class)
protected methods: 2844 (1.7 per class)

Spring is regarded as having very readable code and being
well-designed. These values also seem pretty reasonable though I
think the # of public methods would be higher if we discounted
one-method interfaces (of which Spring has many and of which Scala
would use functions in most cases).

Kindof an interesting back-of-envelope metric...

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 4:47 PM, Tobias Gierke
wrote:
> Hi,
>
> i also suggest looking at real code.
>
> i just picked randomly my audio file class (including related traits etc.):
>
> public methods / fields 49
> public objects / classes / traits 2
> private methods / fields 5
> protected methods / fields 8
> private inner objects / classes / traits : 9
>
> and this has been very carefully designed, all the visibility is correct.
> this is just the main class, there are more objects with the same
> statistics.
>
> now you don't even need to start counting to see why "def" as public makes
> so much more sense than java's way. it's much less typing, and much better
> readability.
>
>
> You're right. I just ran again a check against some of my own code (method
> declarations only) , and the majority is in fact ... public. Hmpf, somehow I
> had the feeling there were more private/protected than public ones. So Scala
> clearly wins in the "less keystrokes, more readability" department - and in
> the "with great power comes great responsibility" department as well ;)
>
> Thanks,
> Tobias
>
> best, -sciss-
>
>
>
> Am 24.05.2010 um 20:38 schrieb Erik Engbrecht:
>
>
>
> Why should those of us who do a lot of exploratory work, or work on
> disciplined teams where people can be trusted to rationally consider access
> qualifiers on their interfaces, be punished because some people can't be
> bothered to type a few characters, much less actually think about it?
>
> There's a big difference between "if you call this method with the wrong
> stuff or in the wrong sequence the object is going to mutate, die a horrible
> death, and possibly take your whole system with it" versus "I may change
> this method later and break your code, so don't call it."
>
> Compensating for programmer idiocy is a losing battle. There's no point in
> designing a language around the idea.
> On Mon, May 24, 2010 at 3:15 PM, Tobias Gierke
> wrote:
> Hi,
>
>
> Much of the necessesity for encapsulation comes from controlling effects,
> especially mutating data. The object must keep itself in a consistent
> state! But if the object is stateless, there's no consistent state to be
> preserved.
>
> So if you use a predominatly functional style the need for strict
> encapsulation diminishes substantially. I'd say enough to warrant
> public-by-default.
>
>
> I tend to disagree. Besides the obvious use-case (encapsulation) , to me
> visibility modifiers also express an intent ( like "This is part of a public
> API and I'm aware of this and will try to not break your stuff"). By having
> only public methods , all those methods could potentially be used by client
> code and therefore are more or less unchangeable once my code has been
> released.
>
> Tobias
>
>
>
>
> On Mon, May 24, 2010 at 2:02 PM, 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."
>
>
> 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
>
>
>
> --
> http://erikengbrecht.blogspot.com/
>
>
> --
> http://erikengbrecht.blogspot.com/
>
>
>
>

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:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv65+cACgkQ5IyIbnMUeTv37wCePw8ZfgqX67GAgeiNkzBc57BH
EpUAn2rbBS6uXO7gleo7rlzdFQsiLIt6
=fjpz
-----END PGP SIGNATURE-----

--
Daniel C. Sobral

I travel to the future all the time.

companion object factory : 6 methods, some in double, some in triple variants (e.g. taking a path String, taking java.io.File, taking java.io.InputStream)
trait for the audiofile : 18 methods, some double with variants, some getter / setter, some shortcuts
the rest is the implementing traits from which is underlying object is constructed

no gods to be seen (or heard).

best, -sciss-

Am 24.05.2010 um 22:01 schrieb David Copeland:

> For non-library code, this feels about right to me, though I was
> expecting more private methods. A class with 49 public methods smells
> like a god object to me.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

That's fair. Lots of single-purpose objects with a small number of
public methods each is certainly a reasonable, testable approach (I'll
quite happily defer to Uncle Bob or Martin Fowler on matters of design).

But since Scala provides very fine-grained visibility controls, wouldn't
it also be reasonable to make those small, single-purpose classes as
minimally-visible as possible? This is a gray area, no doubt;
personally, I lean away from public.

> On Mon, May 24, 2010 at 5:56 PM, Clint Gilbert > 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."
>
>>
>> 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
>

- --
Daniel C. Sobral

I travel to the future all the time.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv68TkACgkQ5IyIbnMUeTsJNgCfVfLQKfshxY18UA2gROFLT1KT
u8MAmwb+UwmeSXSo1YyRaUBvsYQUH65S
=8AFn
-----END PGP SIGNATURE-----

On Mon, May 24, 2010 at 10:01 PM, Daniel Sobral wrote:
> Mind you, the "private val" also defines getters (but, iirc, Scala actually
> compiles access to that as direct field access).

No, it doesn't. On the other hand, private[this] results in direct field access.

Best,
Ismael

There are definite arguments both for and against restricted visibility, and it certainly doesn't help that there is no definitive answer - it all depends on context, your team and your exact use case.
Ultimately, the only true decider is to fall back on science and an evidence-based decision, instead of dogmatically following one or another school of thought on OO theory just go with what actually works in practice!  I define 'works' here to mean stable, fast, maintainable and released quickly.

My experience is that testability wins over any other consideration, get that right and the rest of the design just seems to follow through naturally. So keep methods public, if you have a lot of behaviour that shouldn't be visible to clients then break it out into a separate helper object, and anything that has external or side-effecting dependencies (such as DB or filesystem access) should be injected via an interface/trait.  Basically, follow the SOLID principles, they're more profitable :)



On 24 May 2010 22:36, Ismael Juma <mlists@juma.me.uk> wrote:

On Mon, May 24, 2010 at 10:01 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
> Mind you, the "private val" also defines getters (but, iirc, Scala actually
> compiles access to that as direct field access).

No, it doesn't. On the other hand, private[this] results in direct field access.

Best,
Ismael

--
Kevin Wright

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

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

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

Private methods break encapsulation.

How so?

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/

On Mon, May 24, 2010 at 2:11 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Mon, May 24, 2010 at 1:02 PM, Tobias Gierke <tobias.gierke@code-sourcery.de> wrote:

and thus are poor examples of OO / encapsulation.

It's worth noting that all fields in Scala are private. Always. Cannot be made public. So technically, encapsulation is preserved.

I thought that the way this was explained in the Odersky/Spoon/Venners book was really bad, since it leaves the impression that variables are public by default when, in fact, it's only the methods that are public. Anyone who has been doing OO for any amount of time is going to recoil in horror at the thought of variables being public by default. The statement in the book should have been something like, "Variables in Scala are always private, but the accessor methods are public by default." Or something like that, to soften the impact.
Joey

--
Blog: http://joeygibson.com
Twitter: http://twitter.com/joeygibson
FriendFeed: http://friendfeed.com/joeygibson
Facebook: http://facebook.com/joeygibson

But vars are public by default.  It's the underlying *fields* that are private, and the underlying fields are an implementation detail.  Scala has no direct concept of fields.   One thing you may notice is that you can have:   trait Base {   def foo: String }   case class CaseDerived(foo: String) extends Base class RegularDerived(var foo: String) extends Base   and both of those derived classes work.  You can implement a def as a var or val (but not the reverse).

On Wed, May 26, 2010 at 10:29 AM, Joey Gibson <joey@joeygibson.com> wrote:

On Mon, May 24, 2010 at 2:11 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Mon, May 24, 2010 at 1:02 PM, Tobias Gierke <tobias.gierke@code-sourcery.de> wrote:

and thus are poor examples of OO / encapsulation.

It's worth noting that all fields in Scala are private. Always. Cannot be made public. So technically, encapsulation is preserved.

I thought that the way this was explained in the Odersky/Spoon/Venners book was really bad, since it leaves the impression that variables are public by default when, in fact, it's only the methods that are public. Anyone who has been doing OO for any amount of time is going to recoil in horror at the thought of variables being public by default. The statement in the book should have been something like, "Variables in Scala are always private, but the accessor methods are public by default." Or something like that, to soften the impact.
Joey

--
Blog: http://joeygibson.com
Twitter: http://twitter.com/joeygibson
FriendFeed: http://friendfeed.com/joeygibson
Facebook: http://facebook.com/joeygibson

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