pharo-users@lists.pharo.org

Any question about pharo is welcome

View all threads

Private Methods

CJ
Craig Johnson
Tue, Aug 17, 2021 8:14 PM

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

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
EM
Esteban Maringolo
Tue, Aug 17, 2021 8:31 PM

I don't understand the request?

Wouldn't tagging methods as private (as a first class attribute, and
not only its category) be enough?

What you ask for seems to be a splitted method dictionary of some sort.

Having first class private methods would save you from autocomplete
selector "pollution" of private methods.

Regards!

Esteban A. Maringolo

On Tue, Aug 17, 2021 at 5:14 PM 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

I don't understand the request? Wouldn't tagging methods as private (as a first class attribute, and not only its category) be enough? What you ask for seems to be a splitted method dictionary of some sort. Having first class private methods would save you from autocomplete selector "pollution" of private methods. Regards! Esteban A. Maringolo On Tue, Aug 17, 2021 at 5:14 PM 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
NB
Noury Bouraqadi
Wed, Aug 18, 2021 12:46 PM

Hi Esteban,

Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ?
Thanx
Noury

On Aug 17 2021, at 10:31 pm, Esteban Maringolo emaringolo@gmail.com wrote:

I don't understand the request?

Wouldn't tagging methods as private (as a first class attribute, and
not only its category) be enough?

What you ask for seems to be a splitted method dictionary of some sort.
Having first class private methods would save you from autocomplete
selector "pollution" of private methods.

Regards!
Esteban A. Maringolo
On Tue, Aug 17, 2021 at 5:14 PM 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

Hi Esteban, Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ? Thanx Noury On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo@gmail.com> wrote: > I don't understand the request? > > Wouldn't tagging methods as private (as a first class attribute, and > not only its category) be enough? > > What you ask for seems to be a splitted method dictionary of some sort. > Having first class private methods would save you from autocomplete > selector "pollution" of private methods. > > Regards! > Esteban A. Maringolo > On Tue, Aug 17, 2021 at 5:14 PM 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 >
EM
Esteban Maringolo
Wed, Aug 18, 2021 1:31 PM

Hi Noury,

In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private,
it's a special attribute of the CompiledMethod, so the visibility
doesn't depend on a category name convention, and you can have both
public and private methods sharing a single category. I used that
attribute extensively in the previously described dialects, and it led
to good method categorization, in the case of Dolphin, it had the nice
thing of adding "Private - ..." to the method comment when you toggle
a method as private.

I'm fine with the current state of everything being public, but if we
were to have that public/private distinction that would be the
simplest solution, having a <private> pragma could also work, but I
think that in terms of performance it could impact the lookup. I don't
know, however, if that is what the original request was after.

Best regards,

Esteban A. Maringolo

On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi bouraqadi@gmail.com wrote:

Hi Esteban,

Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ?

Thanx
Noury

On Aug 17 2021, at 10:31 pm, Esteban Maringolo emaringolo@gmail.com wrote:

I don't understand the request?

Wouldn't tagging methods as private (as a first class attribute, and
not only its category) be enough?

What you ask for seems to be a splitted method dictionary of some sort.

Having first class private methods would save you from autocomplete
selector "pollution" of private methods.

Regards!

Esteban A. Maringolo

On Tue, Aug 17, 2021 at 5:14 PM 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

Hi Noury, In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private, it's a special attribute of the CompiledMethod, so the visibility doesn't depend on a category name convention, and you can have both public and private methods sharing a single category. I used that attribute extensively in the previously described dialects, and it led to good method categorization, in the case of Dolphin, it had the nice thing of adding "Private - ..." to the method comment when you toggle a method as private. I'm fine with the current state of everything being public, but if we were to have that public/private distinction that would be the simplest solution, having a <private> pragma could also work, but I think that in terms of performance it could impact the lookup. I don't know, however, if that is what the original request was after. Best regards, Esteban A. Maringolo On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi <bouraqadi@gmail.com> wrote: > > Hi Esteban, > > Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ? > > Thanx > Noury > > On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo@gmail.com> wrote: > > I don't understand the request? > > Wouldn't tagging methods as private (as a first class attribute, and > not only its category) be enough? > > What you ask for seems to be a splitted method dictionary of some sort. > > Having first class private methods would save you from autocomplete > selector "pollution" of private methods. > > Regards! > > Esteban A. Maringolo > > On Tue, Aug 17, 2021 at 5:14 PM 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
GC
Gabriel Cotelli
Wed, Aug 18, 2021 1:45 PM

As Esteban pointed out there are some dialects with proper support for
that. But the semantics is the same as in Pharo, you can still send these
messages.

It is more a warning to the programmer, and the browser shows you these
methods with a particular icon or has tabs so you can easily filter out the
methods marked as private. A least in VA is done by attaching some metadata
to the methods and not changing its source code.

On Wed, Aug 18, 2021 at 10:32 AM Esteban Maringolo emaringolo@gmail.com
wrote:

Hi Noury,

In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private,
it's a special attribute of the CompiledMethod, so the visibility
doesn't depend on a category name convention, and you can have both
public and private methods sharing a single category. I used that
attribute extensively in the previously described dialects, and it led
to good method categorization, in the case of Dolphin, it had the nice
thing of adding "Private - ..." to the method comment when you toggle
a method as private.

I'm fine with the current state of everything being public, but if we
were to have that public/private distinction that would be the
simplest solution, having a <private> pragma could also work, but I
think that in terms of performance it could impact the lookup. I don't
know, however, if that is what the original request was after.

Best regards,

Esteban A. Maringolo

On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi bouraqadi@gmail.com
wrote:

Hi Esteban,

Which first "class attribute" are you referring to? Is it a pragma? Can

you provide an example please ?

Thanx
Noury

On Aug 17 2021, at 10:31 pm, Esteban Maringolo emaringolo@gmail.com

wrote:

I don't understand the request?

Wouldn't tagging methods as private (as a first class attribute, and
not only its category) be enough?

What you ask for seems to be a splitted method dictionary of some sort.

Having first class private methods would save you from autocomplete
selector "pollution" of private methods.

Regards!

Esteban A. Maringolo

On Tue, Aug 17, 2021 at 5:14 PM 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

As Esteban pointed out there are some dialects with proper support for that. But the semantics is the same as in Pharo, you can still send these messages. It is more a warning to the programmer, and the browser shows you these methods with a particular icon or has tabs so you can easily filter out the methods marked as private. A least in VA is done by attaching some metadata to the methods and not changing its source code. On Wed, Aug 18, 2021 at 10:32 AM Esteban Maringolo <emaringolo@gmail.com> wrote: > Hi Noury, > > In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private, > it's a special attribute of the CompiledMethod, so the visibility > doesn't depend on a category name convention, and you can have both > public and private methods sharing a single category. I used that > attribute extensively in the previously described dialects, and it led > to good method categorization, in the case of Dolphin, it had the nice > thing of adding "Private - ..." to the method comment when you toggle > a method as private. > > I'm fine with the current state of everything being public, but if we > were to have that public/private distinction that would be the > simplest solution, having a <private> pragma could also work, but I > think that in terms of performance it could impact the lookup. I don't > know, however, if that is what the original request was after. > > Best regards, > > Esteban A. Maringolo > > On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi <bouraqadi@gmail.com> > wrote: > > > > Hi Esteban, > > > > Which first "class attribute" are you referring to? Is it a pragma? Can > you provide an example please ? > > > > Thanx > > Noury > > > > On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo@gmail.com> > wrote: > > > > I don't understand the request? > > > > Wouldn't tagging methods as private (as a first class attribute, and > > not only its category) be enough? > > > > What you ask for seems to be a splitted method dictionary of some sort. > > > > Having first class private methods would save you from autocomplete > > selector "pollution" of private methods. > > > > Regards! > > > > Esteban A. Maringolo > > > > On Tue, Aug 17, 2021 at 5:14 PM 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 >
DP
David Pennington
Wed, Aug 18, 2021 2:14 PM

I found this useful when creating commercial frameworks for VAST.  For instance, in the printing framework, I used the idea of a turtle (from turtlegraphics) to create pages. All the turtle commands - turn(50) etc - were public but the code that actually created the printing code was all private. Hence purchases knew not to touch the private methods.

David

On 18 Aug 2021, at 14:31, Esteban Maringolo emaringolo@gmail.com wrote:

Hi Noury,

In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private,
it's a special attribute of the CompiledMethod, so the visibility
doesn't depend on a category name convention, and you can have both
public and private methods sharing a single category. I used that
attribute extensively in the previously described dialects, and it led
to good method categorization, in the case of Dolphin, it had the nice
thing of adding "Private - ..." to the method comment when you toggle
a method as private.

I'm fine with the current state of everything being public, but if we
were to have that public/private distinction that would be the
simplest solution, having a <private> pragma could also work, but I
think that in terms of performance it could impact the lookup. I don't
know, however, if that is what the original request was after.

Best regards,

Esteban A. Maringolo

On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi bouraqadi@gmail.com wrote:

Hi Esteban,

Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ?

Thanx
Noury

On Aug 17 2021, at 10:31 pm, Esteban Maringolo emaringolo@gmail.com wrote:

I don't understand the request?

Wouldn't tagging methods as private (as a first class attribute, and
not only its category) be enough?

What you ask for seems to be a splitted method dictionary of some sort.

Having first class private methods would save you from autocomplete
selector "pollution" of private methods.

Regards!

Esteban A. Maringolo

On Tue, Aug 17, 2021 at 5:14 PM 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

I found this useful when creating commercial frameworks for VAST. For instance, in the printing framework, I used the idea of a turtle (from turtlegraphics) to create pages. All the turtle commands - turn(50) etc - were public but the code that actually created the printing code was all private. Hence purchases knew not to touch the private methods. David > On 18 Aug 2021, at 14:31, Esteban Maringolo <emaringolo@gmail.com> wrote: > > Hi Noury, > > In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private, > it's a special attribute of the CompiledMethod, so the visibility > doesn't depend on a category name convention, and you can have both > public and private methods sharing a single category. I used that > attribute extensively in the previously described dialects, and it led > to good method categorization, in the case of Dolphin, it had the nice > thing of adding "Private - ..." to the method comment when you toggle > a method as private. > > I'm fine with the current state of everything being public, but if we > were to have that public/private distinction that would be the > simplest solution, having a <private> pragma could also work, but I > think that in terms of performance it could impact the lookup. I don't > know, however, if that is what the original request was after. > > Best regards, > > Esteban A. Maringolo > > On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi <bouraqadi@gmail.com> wrote: >> >> Hi Esteban, >> >> Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ? >> >> Thanx >> Noury >> >> On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo@gmail.com> wrote: >> >> I don't understand the request? >> >> Wouldn't tagging methods as private (as a first class attribute, and >> not only its category) be enough? >> >> What you ask for seems to be a splitted method dictionary of some sort. >> >> Having first class private methods would save you from autocomplete >> selector "pollution" of private methods. >> >> Regards! >> >> Esteban A. Maringolo >> >> On Tue, Aug 17, 2021 at 5:14 PM 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
RO
Richard O'Keefe
Thu, Aug 19, 2021 6:59 AM

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

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
JM
Jesus Mari Aguirre
Thu, Aug 19, 2021 12:58 PM

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

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 >
EM
Esteban Maringolo
Thu, Aug 19, 2021 1:03 PM

Public/Private is not just a category, it is also a declaration of
what is the interface of the object.
As I said, it's not critical, but I've been working with and without a
"native" private method, and I prefer working with them.

Namespacing is a different animal, and not as simple to implement as
private methods.

Best regards,

Esteban A. Maringolo

On Thu, Aug 19, 2021 at 9:59 AM 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

Public/Private is not just a category, it is also a declaration of what is the interface of the object. As I said, it's not critical, but I've been working with and without a "native" private method, and I prefer working with them. Namespacing is a different animal, and not as simple to implement as private methods. Best regards, Esteban A. Maringolo On Thu, Aug 19, 2021 at 9:59 AM 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
RO
Richard O'Keefe
Fri, Aug 20, 2021 8:19 AM

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

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