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 <rao...@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 <jmariagui...@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 <rao...@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 <cr...@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
