You are very right - it hadn’t sunk in that a compiled method attribute would give you what you want - but then we are back to an easily extendible browser … which I think calypso actually is … hmm should be quite easily doable to get all described here - and show private methods in a private category like Dolphin did (somewhat related, I wish class methods worked this way too - I hate flipping between class/instance mode)
Anyway, a great topic for making you think a bit more. Tim > On 23 Aug 2021, at 15:06, Esteban Maringolo <emaring...@gmail.com> wrote: > > 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
