- Pharo-users - lists.pharo.org

Using new VM but can't find any log files

by David Pennington

Hi there. I have installed the new M1 VM that supposedly gives much better information into a log file. However, my image is still disappearing such that it now doesnât last more than 12 hours before going. I have searched for these log files but I canât find any. Can anyone help me in this as I am close the throwing this all into the bin if I canât keep my simple web site going regularly. My clients are not happy, as you can imagine and telling me to just go with a Blogger blog! I donât want to do that so can anyone help? David

Aug. 28, 2021

Re: uFFI: Calling conventions?

by egarrulo

>> Yesterday we have implemented the image side part in P10 to correctly Â Â honour the calling convention. Does this imply that uFFI doesn't work correctly on current images? Because uFFI should have been available since Pharo 8, according to the uFFI manual.Â Or is it a revamped implementation? >> On the other hand, you are asking about ThisCall. This calling Â Â conventionis only relevant in 32bits systems. What is your target Â Â system/library? Does it not exist as 64-bit library? Unfortunately it is a legacy library with no 64 bit version. No problem, because I can write a wrapper, yet I was wondering if Pharo offered any facilities to avoid that. Thank you for the information. ---------------------------------------------------------------------- > Message: 1 > Date: Thu, 26 Aug 2021 15:38:48 +0200 > From: "tesonep(a)gmail.com" <tesonep(a)gmail.com> > Subject: [Pharo-users] Re: uFFI: Calling conventions? > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Message-ID: > <CAM9-ED+DYAJdOF0GfBcypmV9cQqufmSzUmC51EaLRzS2ycsPWQ(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="0000000000004711e205ca767def" > > Hi All, > The answer is yes and no. > Let's go step by step. > To declare the calling convention a class can override the method > #ffiCallingConvention. Returning a Symbol representing the Calling > Convention. > > Yesterday we have implemented the image side part in P10 to correctly > honour the calling convention. > I have implemented it for X86 but this can be easily extended to ARM32 > (ARM64 has a single calling convention). > If this fix is useful, it can be backported to P9. > > However, this only works for X86_64 as it depends on the new FFI > implementation. We still do not have an X86 32 bits VM, it is possible to > compile it from sources, but we are not distributing it. > > In X86_64 only exists the Windows and the GNU calling convention, we are > supporting both. > > On the other hand, you are asking about ThisCall. This calling convention > is only relevant in 32bits systems. What is your target system/library? > Does it not exist as 64-bit library? > > Thanks > > On Tue, Aug 24, 2021 at 9:33 PM egarrulo <egarrulo(a)gmail.com> wrote: > >> Hi all, >> >> I haven't found any information on calling conventions in the "Unified >> FFI - Calling Foreign Functions from Pharo" manual. What conventions are >> available, please? >> >> If the ThisCall[1] convention isn't supported, could it be implemented >> in code with some boilerplate? >> >> Thank you. >> >> -- >> >> [1] ThisCall works like StdCall, but the first parameter - the "this" >> pointer - is passed via the ECX register. >> >>

Aug. 27, 2021

Re: uFFI: Calling conventions?

by tesonep＠gmail.com

Hi All, The answer is yes and no. Let's go step by step. To declare the calling convention a class can override the method #ffiCallingConvention. Returning a Symbol representing the Calling Convention. Yesterday we have implemented the image side part in P10 to correctly honour the calling convention. I have implemented it for X86 but this can be easily extended to ARM32 (ARM64 has a single calling convention). If this fix is useful, it can be backported to P9. However, this only works for X86_64 as it depends on the new FFI implementation. We still do not have an X86 32 bits VM, it is possible to compile it from sources, but we are not distributing it. In X86_64 only exists the Windows and the GNU calling convention, we are supporting both. On the other hand, you are asking about ThisCall. This calling convention is only relevant in 32bits systems. What is your target system/library? Does it not exist as 64-bit library? Thanks On Tue, Aug 24, 2021 at 9:33 PM egarrulo <egarrulo(a)gmail.com> wrote: > Hi all, > > I haven't found any information on calling conventions in the "Unified > FFI - Calling Foreign Functions from Pharo" manual. What conventions are > available, please? > > If the ThisCall[1] convention isn't supported, could it be implemented > in code with some boilerplate? > > Thank you. > > -- > > [1] ThisCall works like StdCall, but the first parameter - the "this" > pointer - is passed via the ECX register. > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 26, 2021

The ideal font for Pharo

by tau

I've been bothered by the assignement operator (:=) and the way the colon and the equal sign aren't verticaly aligned when coding in Pharo. So I began a quest to find a pharo-friendly font were the colon and equal sign are aligned. Turn out most monospaced fonts don't qualify but I did find the following fonts: * Fira Code (https://fontlibrary.org/en/font/fira-code) has a := ligature that doesn't work in Pharo. * Iosevka extended (https://fontlibrary.org/en/font/iosevka-extended) also has a := ligature that doen't work in Pharo. * Mononoki (https://fontlibrary.org/en/font/mononoki) has the two characters properly aligned but I dislike the appareance of that font. The @, in particular, looks like it comes from a low-resolution terminal from the early '80s. * Fantasque Sans Mono (https://fontlibrary.org/en/font/fantasque-sans-mono) has perfectly aligned colon and equal sign and moreover has a nice informal look. So, Fantasque Sans Mono is now my favorite font for coding in Pharo ð.

Aug. 25, 2021

uFFI: Calling conventions?

by egarrulo

Hi all, I haven't found any information on calling conventions in the "Unified FFI - Calling Foreign Functions from Pharo" manual. What conventions are available, please? If the ThisCall[1] convention isn't supported, could it be implemented in code with some boilerplate? Thank you. -- [1] ThisCall works like StdCall, but the first parameter - the "this" pointer - is passed via the ECX register.

Aug. 24, 2021

Re: Private Methods

by Tim Mackinnon

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 <emaringolo(a)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(a)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(a)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(a)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(a)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(a)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

Aug. 23, 2021

Re: Private Methods

by Torsten Bergmann

Hi, Smalltalk should be readable - so I dislike the prefix approach like "_" or "priv". Pharo has a unified property API so one can annotate both: methods and classes (unfortunately not yet serialized into Tonel). It could be used to depict a scope or other: Â Â Â Â MyClass propertyAt: #scope put: #private. The rest is a tool issue for calls, autocompletion, check for local/private/protected senders, ... Regards T. Am 23.08.2021 um 14:05 schrieb Esteban Maringolo: > 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(a)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(a)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(a)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(a)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(a)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

Aug. 23, 2021

Re: Private Methods

by Esteban Maringolo

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(a)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(a)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(a)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(a)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(a)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

Aug. 23, 2021

Re: Private Methods

by Tim Mackinnon

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(a)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(a)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(a)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(a)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

Aug. 23, 2021

[ANN] Stargate v6.1.1 [v6.1.1] released!

by Buenos Aires Smalltalk

Aug. 20, 2021