- Pharo-users - lists.pharo.org

Re: [Pharo-users] Naming parameters - conventions?

by Richard Sargent

Tim Mackinnon wrote > Hi everyone, something Iâve meant to ask over the years, as Iâve seen lots > of variation and was taught something else in the day... > > What is the suggested way of naming parameters? > > I was taught {âaâ/âanâ}DataType, so it would be: > > #name: aString > > Which works ok (although falls apart if you refactor as the tools donât > interpret it - although I guess could be improved to do so) > > However often I find myself wanting to communicate a bit better as in: > > #name: fullNameString > > Which isnât strictly a datatype (and I tend to leave out the a/an when I > do this). But it feels a bit off piste and it does make me consider > whether my selector is named badly and should be: > > #fullName: aString > > Which takes me back to the convention I learned long ago. > > This said however, we often need to match similar #on:do, #in: generic > selector names and then itâs not always obvious the intent of parameter. > > Any thoughts to share? In my opinion, worth what you pay for it, the goal is to communicate and set the reader's expectations. You want the reader to know what kind of behaviours the argument should provide. So, when creating a setter method, it is sufficient to name the argument "aString". The method selector is telling you the purpose of the string. The argument is telling you that it is no more and no less than a string. It isn't trying to convey that there is a structure to that string. Just that the name is a string. Likewise, when naming a parameter for a more complex method you may need to say more, depending on what the selector itself says. e.g. #blahBlahBlahWithName: can easily work with "aString". Conversely, a method that takes multiple string arguments needs to effectively distinguish them from each other. e.g. #blahBlahBlahWithName:address:telephone: needs to do better than Dr. Seuss (aString1, aString2, etc.) In this example, I tend to use e.g. "nameString", "addressString", and "telephoneString". This conveys the purpose of each argument and identifies the behaviours one should expect. I am *not* a fan of argument names like "aNameString", since that can mislead readers into expecting name-specific behaviours from the argument. > I ask because for exercism, we should try and set a good example. > > Tim > > Sent from my iPhone -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 12, 2018

Re: [Pharo-users] Thoughts on mini Smalltalk exercises

by Ben Coman

On 11 July 2018 at 22:43, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - Iâm trying to help Sam kickstart Pharo working Ian the exercism platform. For those less familiar, exercism is a platform with a series of exercises that users/students âcheckoutâ and then run a test to guide them through completing the code to then progress to the next challenge. There is also the ability to comment on each otherâs progress and see examples of otherâs solutions. Most languages are more traditional file based examples, so it would be nice to have Smalltalk as something a bit different. Although we think Tonel 2 will be an excellent vehicle for participating alongside other languages as it helps us fit in a little easier (nice how all our initiatives are coming together to make this easy). > > As you can imagine, exercises start out very simple and then increase in complexity. My question however, is about the early exercise like HelloWorld, LeapYear etc. > > These tend to be single method problems of just a few lines, requiring no instance variables (this all comes later). > > Iâm wondering about peopleâs thoughts on whether we should introduce early Smalltalk examples as just class methods and later introduce instance methods and âclass constructor methods â? Or is this more confusing for students? Essentially we are battling with the familiarity of the C âmainâ method - and looking at python and ruby solutions, they initially start with no objects and just main style methods. > > E.g. hello world can be simply: HelloWorld sayHello. vs HelloWorld new sayHello. > > I can see proâs/conâs either way - but wondering what others think. I've installed Sam's PR and my main thought is that the System Browser defaults to the instance side, so its easier for fresh students to misplace code when it ends up on the class side, when they close a browser and open a new one. The unit test the students run takes care the of needing to send #new to get an object, so I think its simpler to keep implementations on the instance-side. One downside is that the Quality Assistant indicates that utility methods (having no reference to instance variables) should belong on the class side. It might be good that this warning is disabled globally when the Exercism tool is installed. I think using a Manifest to do this would look complicated to newcomers. Later on some specific Factory Pattern exercises might be useful to introduce students to using class-side methods. cheers -ben

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Sean P. DeNigris

Paul DeBruicker wrote > It also seems like a "how much milk do you like in your coffee?" choice > where the tradeoffs between one vs the other isn't high and the code in > action will let you know whether you've got it right. +1. I also use both. My heuristic is for shorter methods, and methods with one argument, I tend to lean toward fullNameString and when I need to differentiate multiple arguments or reference the arg way down in a method (probably a good sign to refactor) I lean the other way. But I think Paul said it best that it's probably more a personal style/aesthetic choice than anything worth spending a lot of energy on. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Paul DeBruicker

I generally go for intention revealing (e.g. fullName) because the class of the parameter can change arbitrarily. e.g. your aString might become a Name object that can answer something useful when you know just the first or family name. But I also mostly write code for my own consumption. If there is anything recommended/specified in https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X I'd use it in training materials. I'm away from the house but can look in my copy later if no one else chimes in with a better answer. It also seems like a "how much milk do you like in your coffee?" choice where the tradeoffs between one vs the other isn't high and the code in action will let you know whether you've got it right. Tim Mackinnon wrote > Hi everyone, something Iâve meant to ask over the years, as Iâve seen lots > of variation and was taught something else in the day... > > What is the suggested way of naming parameters? > > I was taught {âaâ/âanâ}DataType, so it would be: > > #name: aString > > Which works ok (although falls apart if you refactor as the tools donât > interpret it - although I guess could be improved to do so) > > However often I find myself wanting to communicate a bit better as in: > > #name: fullNameString > > Which isnât strictly a datatype (and I tend to leave out the a/an when I > do this). But it feels a bit off piste and it does make me consider > whether my selector is named badly and should be: > > #fullName: aString > > Which takes me back to the convention I learned long ago. > > This said however, we often need to match similar #on:do, #in: generic > selector names and then itâs not always obvious the intent of parameter. > > Any thoughts to share? > > I ask because for exercism, we should try and set a good example. > > Tim > > Sent from my iPhone -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 11, 2018

Naming parameters - conventions?

by Tim Mackinnon

Hi everyone, something Iâve meant to ask over the years, as Iâve seen lots of variation and was taught something else in the day... What is the suggested way of naming parameters? I was taught {âaâ/âanâ}DataType, so it would be: #name: aString Which works ok (although falls apart if you refactor as the tools donât interpret it - although I guess could be improved to do so) However often I find myself wanting to communicate a bit better as in: #name: fullNameString Which isnât strictly a datatype (and I tend to leave out the a/an when I do this). But it feels a bit off piste and it does make me consider whether my selector is named badly and should be: #fullName: aString Which takes me back to the convention I learned long ago. This said however, we often need to match similar #on:do, #in: generic selector names and then itâs not always obvious the intent of parameter. Any thoughts to share? I ask because for exercism, we should try and set a good example. Tim Sent from my iPhone

July 11, 2018

Re: [Pharo-users] Thoughts on mini Smalltalk exercises

by Tim Mackinnon

Hi guys, theyâre all great ideas - but I guess I should have added the caveat - âthat you can easily testâ. It sounds like maybe using class methods puts it closer to the simpler camp you are suggesting - and I would like to push the idea of using the debugger to create the missing method (a unique feature we can sing about). Weâre trying to help bridge a balance between unique and familiar, and to be honest the quicker we can move people to the harder problems the better. Itâs not clear to me if you can just invent new problems - but if so, we might hit you guys up for some more ideas. Tim Sent from my iPhone Sent from my iPhone > On 11 Jul 2018, at 21:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 11 Jul 2018, at 22:17, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Le 11/07/2018 Ã 16:43, Tim Mackinnon a Ã©crit : >>> I can see proâs/conâs either way - but wondering what others think. >> >> IMHO, the simpler the better, particularly for users with no knowledge >> on Pharo. >> >> Hello world could be class-less just: Transcript show: 'Hello world' >> >> Hilaire >> >> -- >> Dr. Geo >> http://drgeo.eu > > Even shorter: > > 'Hello World!' crLog. > > A variant using the Growl disappearing popup: > > self inform: 'Hello World!'. > > Using a dialog: > > UIManager default alert: 'Hello World!'. > > Using a window: > > 'Hello World!' asMorph openInWindow. > > For real terminal output, there is this possibility: > > Stdio stdout << 'Hello World!'; lf; flush. > > All these are nice alternatives that can be used to explain different approaches/techniques, although they might be beyond what is expected. > > Sven

July 11, 2018

Re: [Pharo-users] Email Google API for pharo

by Sean P. DeNigris

Peter UhnÃ¡k wrote > I've used it last year or so and it was very nice to use. Anything public we can use for inspiration? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 11, 2018

Re: [Pharo-users] Thoughts on mini Smalltalk exercises

by Sven Van Caekenberghe

> On 11 Jul 2018, at 22:17, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 11/07/2018 Ã 16:43, Tim Mackinnon a Ã©crit : >> I can see proâs/conâs either way - but wondering what others think. > > IMHO, the simpler the better, particularly for users with no knowledge > on Pharo. > > Hello world could be class-less just: Transcript show: 'Hello world' > > Hilaire > > -- > Dr. Geo > http://drgeo.eu Even shorter: 'Hello World!' crLog. A variant using the Growl disappearing popup: self inform: 'Hello World!'. Using a dialog: UIManager default alert: 'Hello World!'. Using a window: 'Hello World!' asMorph openInWindow. For real terminal output, there is this possibility: Stdio stdout << 'Hello World!'; lf; flush. All these are nice alternatives that can be used to explain different approaches/techniques, although they might be beyond what is expected. Sven

July 11, 2018

Re: [Pharo-users] Thoughts on mini Smalltalk exercises

by Hilaire

Le 11/07/2018 Ã 16:43, Tim Mackinnon a Ã©critÂ : > I can see proâs/conâs either way - but wondering what others think. IMHO, the simpler the better, particularly for users with no knowledge on Pharo. Hello world could be class-less just: Transcript show: 'Hello world' Hilaire -- Dr. Geo http://drgeo.eu

July 11, 2018

Re: [Pharo-users] Request for Windows test

by Ben Coman

On 11 July 2018 at 18:19, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > A Windows user reported to me difficulty to start Dr. Geo. > > Although I had success to run it in a Windows system, I will be glad if > some of you would mind testing it on their windows system, and report to > me success or failure along the used Windows system. On Windows 10... when I doubleclick "DrGeo.bat" I get a message... Windows protected your PC. Windows Defender SmartScreen prevented an unrecognised app from starting. Running this app might put your PC at risk. and after clicking "More Info" Application: DrGeo.bat Publisher: Unknown publisher and I could click "Run anyway" after which DrGeo opened fine, and I could "Open a sketch" > "Examples", etc... cheers -ben

July 11, 2018