As many have described, I’ve seen this work reasonably well too - while I’ve seen the pvt prefix convention, I’ve also seen _name used to - which I felt was marginally better (it also means private methods get grouped at the top of the “all list” and not alphabetically in the middle’ish (but it’s a minor thing as browser tools can filter appropriately anyway, and to be honest, showing private at the bottom or in a separate place is better).

It is worth saying however - that lots if pvt methods can be a code smell - it may be better to move them to a separate “policy object” and then focus on better delegation options - which I believe is where Pharo is heading with variables as first class objects (and hopefully Marcus will cover in the U.K. Smalltalk Meetup this week).

Too often we end up up with lots of sub classing and overriding and privatising - when there is a new object that could group all this stuff and the methods can be public in that delegate - while the delegate itself is a “private” object.

I think this should be explored more actually.

Tim

On 20 Aug 2021, at 11:19, Richard O'Keefe raoknz@gmail.com wrote:

One of the claimed benefits of object-oriented programming is ENCAPSULATION.
The idea is that one of the ways a language helps you is by making some errors
difficult or impossible to express.
One of the things you need to understand an object is its INVARIANT.
For example, astc's SortedCollection includes

methods for: 'checking'
invariant
^(opposite isNil or: [
opposite isKindOf: DyadicBlock]) and: [
super invariant and: [
(sortBlock
ifNil:    [(offset + 2 to: offset + size) allSatisfy: [:i |
(array at: i-1) <= (array at: i)]]
ifNotNil: [(sortBlock respondsTo: #value:value:) and: [
[(offset + 2 to: offset + size) allSatisfy: [:i |
(sortBlock value: (array at: i-1)
value: (array at: i))]]]])]]

Private methods are allowed to break the invariant.
Public methods are not.

For example, consider reversing a SortedCollection.
Part of this changes the order of the elements, and can be
shared with OrderedCollection.  Part of it swaps the arguments
of the sortBlock, and cannot be shared.

methods for: 'rearranging'
pvtPrereverse
|t|
opposite
ifNil: [
sortBlock ifNil: [sortBlock := Magnitude defaultSortBlock].
t := sortBlock.
opposite := sortBlock.
sortBlock := [:x :y | t value: y value: x]]
ifNotNil: [
t := sortBlock.
sortBlock := opposite.
opposite := t].

If this method could be called from "outside", it would certainly break
the invariant and leave the object in an unusable state.

Now a style rule doesn't quite prevent this method being called by
another object.
It is necessary to make sure that #perform: and friends cannot break
encapsulation
either, and this astc does by simply not creating Selector objects for
private methods.

Yes, it is a small increase in the complexity of the language, however

• you are not forced to write private methods
• if you run code that uses the pvt* convention in a Smalltalk that does
  not use that convention, it works, it's just not safe any longer
• it is not an arbitrary addition to the language, it is a restriction that
  makes programming easier.

Let's look at one additional example.
Behavior>>
new
^ self basicNew initialize

This means that any object can forcibly reinitialize any object it can
reach at any time.  In astc, it's

new
"other checks"
^self pvtNew pvtPostNew

and an object cannot be reinitialised against its will.

There is a long standing tradition of "program for the typical case and trust
the omniscient programmer to know what will probably work and what won't"
in Smalltalk.  This is why in many Smalltalks
aCollection addAll: aCollection
or
aCollection removeAll: aCollection
can go insane for some common collections.  And one DOES get away
with it most of the time.  It's typically when someone else triest to use your
code and doesn't know the assumptions you didn't bother to write down
that things go wrong.  It's obvious that Pharo has got to where it
amazingly well is without the "bondage and discipline" of, say, Ada or
Agda.  But there is a reason why Pharo has lint checking on by default.

On Fri, 20 Aug 2021 at 00:59, Jesus Mari Aguirre jmariaguirre@gmail.com wrote:

Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java

El jue., 19 ago. 2021 9:00, Richard O'Keefe raoknz@gmail.com escribió:

Many years ago there was a proposal in the Squeak mailing list about enforcing
a naming convention, "pvt",  I implemented that in my Smalltalk system.  The
compiler enforces the rule that pvt.[A-Z].* message can only be sent to
(self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)?
in a class method or
(self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)?
in an instance method.
There are currently
9412 public selectors
793 pvt* selectors and
23 private* selectors,
where the last group is methods that I want to be private in some sense but
cannot do with this machinery.  (For example, calling a "private" method on
another object known to be of the same class.)

I think the evidence shows that this works well enough to be useful, even if it
isn't quite as expressive as I'd like.  And what that means is that
this can be
done with a style check, using the machinery Pharo already has for style checks.

On Wed, 18 Aug 2021 at 08:14, Craig Johnson craig@hivemind.net wrote:

Hi All,

Just a newb off-the-wall question.

Is there any good reason why we can't create a true private method in a
Pharo class by putting that method inside an instance or class variable
as a lambda (block).

This would reduce one of my biggest bugbears with Pharo, namely the
pollution of the global namespace with every single message name in the
entire system.

Craig

If something, I'd rather have _ as a prefix indicating a private
method, very much like Dart does.
But why use a "syntax" trick when it could be an attribute of the
CompiledMethod itself?

As for many private methods being a code smell... it could be, but it
depends, until you find the right abstractions you might want to keep
private all the stuff that is causing the smell :-)

Esteban A. Maringolo

On Mon, Aug 23, 2021 at 8:06 AM Tim Mackinnon tim@testit.works wrote:

As many have described, I’ve seen this work reasonably well too - while I’ve seen the pvt prefix convention, I’ve also seen _name used to - which I felt was marginally better (it also means private methods get grouped at the top of the “all list” and not alphabetically in the middle’ish (but it’s a minor thing as browser tools can filter appropriately anyway, and to be honest, showing private at the bottom or in a separate place is better).

It is worth saying however - that lots if pvt methods can be a code smell - it may be better to move them to a separate “policy object” and then focus on better delegation options - which I believe is where Pharo is heading with variables as first class objects (and hopefully Marcus will cover in the U.K. Smalltalk Meetup this week).

Too often we end up up with lots of sub classing and overriding and privatising - when there is a new object that could group all this stuff and the methods can be public in that delegate - while the delegate itself is a “private” object.

I think this should be explored more actually.

Tim

On 20 Aug 2021, at 11:19, Richard O'Keefe raoknz@gmail.com wrote:

One of the claimed benefits of object-oriented programming is ENCAPSULATION.
The idea is that one of the ways a language helps you is by making some errors
difficult or impossible to express.
One of the things you need to understand an object is its INVARIANT.
For example, astc's SortedCollection includes

methods for: 'checking'
invariant
^(opposite isNil or: [
opposite isKindOf: DyadicBlock]) and: [
super invariant and: [
(sortBlock
ifNil:    [(offset + 2 to: offset + size) allSatisfy: [:i |
(array at: i-1) <= (array at: i)]]
ifNotNil: [(sortBlock respondsTo: #value:value:) and: [
[(offset + 2 to: offset + size) allSatisfy: [:i |
(sortBlock value: (array at: i-1)
value: (array at: i))]]]])]]

Private methods are allowed to break the invariant.
Public methods are not.

For example, consider reversing a SortedCollection.
Part of this changes the order of the elements, and can be
shared with OrderedCollection.  Part of it swaps the arguments
of the sortBlock, and cannot be shared.

methods for: 'rearranging'
pvtPrereverse
|t|
opposite
ifNil: [
sortBlock ifNil: [sortBlock := Magnitude defaultSortBlock].
t := sortBlock.
opposite := sortBlock.
sortBlock := [:x :y | t value: y value: x]]
ifNotNil: [
t := sortBlock.
sortBlock := opposite.
opposite := t].

If this method could be called from "outside", it would certainly break
the invariant and leave the object in an unusable state.

Now a style rule doesn't quite prevent this method being called by
another object.
It is necessary to make sure that #perform: and friends cannot break
encapsulation
either, and this astc does by simply not creating Selector objects for
private methods.

Yes, it is a small increase in the complexity of the language, however

• you are not forced to write private methods
• if you run code that uses the pvt* convention in a Smalltalk that does
  not use that convention, it works, it's just not safe any longer
• it is not an arbitrary addition to the language, it is a restriction that
  makes programming easier.

Let's look at one additional example.
Behavior>>
new
^ self basicNew initialize

This means that any object can forcibly reinitialize any object it can
reach at any time.  In astc, it's

new
"other checks"
^self pvtNew pvtPostNew

and an object cannot be reinitialised against its will.

There is a long standing tradition of "program for the typical case and trust
the omniscient programmer to know what will probably work and what won't"
in Smalltalk.  This is why in many Smalltalks
aCollection addAll: aCollection
or
aCollection removeAll: aCollection
can go insane for some common collections.  And one DOES get away
with it most of the time.  It's typically when someone else triest to use your
code and doesn't know the assumptions you didn't bother to write down
that things go wrong.  It's obvious that Pharo has got to where it
amazingly well is without the "bondage and discipline" of, say, Ada or
Agda.  But there is a reason why Pharo has lint checking on by default.

On Fri, 20 Aug 2021 at 00:59, Jesus Mari Aguirre jmariaguirre@gmail.com wrote:

Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java

El jue., 19 ago. 2021 9:00, Richard O'Keefe raoknz@gmail.com escribió:

Many years ago there was a proposal in the Squeak mailing list about enforcing
a naming convention, "pvt",  I implemented that in my Smalltalk system.  The
compiler enforces the rule that pvt.[A-Z].* message can only be sent to
(self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)?
in a class method or
(self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)?
in an instance method.
There are currently
9412 public selectors
793 pvt* selectors and
23 private* selectors,
where the last group is methods that I want to be private in some sense but
cannot do with this machinery.  (For example, calling a "private" method on
another object known to be of the same class.)

I think the evidence shows that this works well enough to be useful, even if it
isn't quite as expressive as I'd like.  And what that means is that
this can be
done with a style check, using the machinery Pharo already has for style checks.

On Wed, 18 Aug 2021 at 08:14, Craig Johnson craig@hivemind.net wrote:

Hi All,

Just a newb off-the-wall question.

Is there any good reason why we can't create a true private method in a
Pharo class by putting that method inside an instance or class variable
as a lambda (block).

This would reduce one of my biggest bugbears with Pharo, namely the
pollution of the global namespace with every single message name in the
entire system.

Craig