- Pharo-users - lists.pharo.org

As a SmallTalk youngster: A few questions...

by ian

Hi All, Learning; Please bear with me. Scenario: 1. Class>>User. InstVars: #(this that other userStatus userMeta) 2. Class>>UserManager (singleton). Instvars: users (RcIdentityBag: users) When User is instantiated all its' instVars are populated correctly. Nested objects as well. To insert the User into the UserManager singleton instVar I created an add: method on the instance side of UserManager to pass the User to the UserManager as per: --- add: aUser users add: aUser --- This works and I am able to created my database of users. The difficulty I am having is that when I want to query the UserManager db with something like: --- RcIdentityBag(users) select: [ :each | each name := 'somename' ] --- It seems that currently the only I know how to do this is to create a select: method in UserManager simply to pass the desired search string into the UserManager class such that I can use the Collection Classes api to do the actual work, as per: --- Pardon the not so smalltalky code --- UserManager>>select: aString | resultSet | resultSet := users select: [ :each | each name := aString ]. ^resultSet --- I believe I read somewhere that in order to avoid this clunkiness that I could refer to the users collection in UserManager via a symbol and access the api of the identitySet directly. Something like: --- UserManager class>>current UserGlobals at: #FOO put users. ... --- But when I do this I am unable to do something like: --- #FOO add: user --- Do to doesNotUndestand exceptions. Finally Questions: 1. Am I totally off the mark with the use of smalltalk symbols? 2. Must I create the API in the managing class to perform the specific functions I need from the collection API with respect to querying the collection? 3. Is there a smalltalk way of doing this properly that I missed (reading all the docs I can find in random order based of info I need - probably missing the finer points)? Any nudge in the correct direction would be greatly appreciated. Thanks!

Aug. 17, 2019

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

by TedVanGaalen

Sorry for the later response. yes here too: resizing didn't cause problems. Drastic work around :o) : I have now installed Pharo 7.0 on my other Windows 10 PC, Using the Pharo Launcher. ** Everything works ok, on my windows machine. installed Seaside, my own app dev from .st fileins. etc. Great! Enjoying the improved 7.0 version. Thanks to all Kind regards TedvG ** (still having a problem here with Pharo Launcher) If I do "save as" in Pharo, the new image does NOT appear in the launcher Window, why is that? Pharo does also not respect the traditional "save as" default renaming. It does not supply the old image name name with the new incremented .number trailing. Solved the problem by putting my most recent .image .changes .source files into a separate independent folder and making a Windows file association to the new VM. which by the way is my preferred way of working, completely local, off line, putting everything related to a single app development in one autonomous folder. (I don't use git for my own developments..) Now, to work with an .image, I simply click on it and the VM starts with that image, what can be simpler? I don't need the nested folder structure the Pharo Launcher uses. In practice, this means the Pharo Launcher is only useful to me to get the most recent VM & image, whenever the need arises. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 17, 2019

Re: [Pharo-users] Why do I not see the transactions when opening a customer

by Roelof Wobben

Aug. 17, 2019

Re: [Pharo-users] Why do I not see the transactions when opening a customer

by Richard O'Keefe

Good-oh. Looking at Bankaccounts - the name should be singular, not plural - Smalltalk uses baStudlyCaps > Call it BankAccount. - you not only provide a getter for the password, but a setter! This means that malevolent/broken code can do aBankAccount password: 'PWNED!'. and then supply the new password 'PWNED!' whenever a password is needed. > The password must be supplied when a BankAccount is changed and it should not be settable afterwards (except perhaps with a master key). - #addToBankAccount: is an unhelpful name; we know it's adding to a BankAccount because that is where it is. But what is it adding? (Hint: an account might have more than one customer in the real world, so we might need to distinguish between #addCustomer: and) > #addTransaction: , which would be a better name. - There is a missing method. When you ask a bank account to report a secret, *it* should check the password. > add queryBalance: pwd ^password = pwd ifTrue: [transactions detectSum: [:each | each amount]] ifFalse: [self error: 'wrong password'] Transactions - This too should be singular, not plural. > Rename it to Transaction. - You know it is unfinished. Customer - You know it is unfinished. - Smalltalk uses baStudlyCaps style. The instance variable 'bankaccounts' is two words run together. > Change it to 'bankAccounts'. - The very first method has two style issues and a major flaw. AddBankAccountToCustomer: bankaccount [ bankaccounts add: bankaccounts ] - Style flaw one: method names are expected to begin with a lower case letter, not a capital. (That's C#.) - Style flaw two; we *knew* it's adding to a customer, because that's where it is. > Rename to #addBankAccount: - The major flaw is that the argument 'bankaccount' is ignored, while the 'bankaccounts' collection is added TO ITSELF. This is one of the rare occasions when a type checker would have caught a mistake. > Revise to addBankAccount:aBankAccount [ bankAccounts addLast: aBankAccount. ] - You have a setter, #bankaccounts:. WHY? This should be a completely private variable, initialised when the Customer object is created, and never reassigned thereafter. > Delete that setter. Customer >> AddBankAccountToCustomer: bankaccount [ bankaccounts add: bankaccounts. ] On Sat, 17 Aug 2019 at 21:59, Roelof Wobben <r.wobben(a)home.nl> wrote: > Sorry, then a pointed to a wrong repo > this is the repo with smalltalk code : > > https://github.com/rwobben/banking > > Roelof > > > > Op 17-8-2019 om 11:25 schreef Richard O'Keefe: > > https://github.com/rwobben/bankaccount > points to a repository with C# code, so I cannot comment on the Smalltalk. > There is, however, a striking thing about the C# code, qua C#, that is > worth mentioning. > > It is not encapsulated. > > Let's start with the most obvious one. > A bank account has a password, and you are > supposed to provide the right password in order > to get information from it. > > Your interface *reveals* the password, so > malicious code can do > var pass = theBankAccount.password; > and then provide the password back. What's > needed is something like > > var balance = theBankAccount.queryBalance(pass); > > where passwords go *in* to theBankAccount but never ever > ever come *out*. > > Another thing is that a BankAccount belongs to a specific > Customer. There's a good way and a bad way to manage this. > The bad way is for the caller to create a new account that > belongs to nobody, and then *tell* the Customer "here is a > new account". With this interface, you could tell any > number of Customers that they own the account. That's > possible in the real world, but in the challenge, it isn't. > The good way is to *ask* the Customer "please create a new > account and tell me what it is", and have no way to force > a Customer to accept an account willy nilly. That way a > Customer can be certain that the accounts it is holding > belong to it and it alone. > > Or it could be were it not for a major encapsulation issue. > The idea of encapsulation is that > EVERY CHANGE TO AN OBJECT'S STATE MUST BE MADE BY THAT OBJECT > including the start of owned containers. > > In Java, for example, you might have > public class Customer { > private final ArrayList<Account> accounts = new ArrayList<Account>(); > ... > public List<Account> getAccounts() { > return Collections.unmodifiableList(accounts); > } > ... > public Account newAccount(...details...) { > final Account a = new Account(...details...'); > accounts.add(a); > return a; > } > ... > } > If you are going to provide access to a collection, > (1) make the collection immutable in the first place, or > (2) return an immutable view of it, or > (3) best of all, DON'T provide access to the collection > but provide queries that extract just the information you > want to make available. > > This has nothing to do with Java or Smalltalk or C# as such; > encapsulation is object-oriented-programming 102. > > For what it's worth, I used to be a University lecturer, and > it was MUCH harder for students to grasp encapsulation than > to grasp recursion. I have no idea why. Just pretend that you > are a nice little object surrounded by malevolent pranksters > who can force you to do anything in your interface, and make > sure they cannot harm you. > > Oh, when I asked about the source of the challenge, what I was > getting at was "is this your paraphrase of the challenge, in > which case please tell us to find the original, or is this > the actual unmodified original text, in which case --ing h---, > you have my profound sympathy." > > This looks like a garbled version of an exercise that I did > a little over 10 years ago, which I found in a Java-based book > whose details I unfortunately forgot to record. Right down to > the names of the classes! That is why I am pretty sure that > there is a description of the problem somewhere that makes sense. > > >

Aug. 17, 2019

Re: [Pharo-users] Why do I not see the transactions when opening a customer

by Roelof Wobben

Aug. 17, 2019

Re: [Pharo-users] Why do I not see the transactions when opening a customer

by Richard O'Keefe

https://github.com/rwobben/bankaccount points to a repository with C# code, so I cannot comment on the Smalltalk. There is, however, a striking thing about the C# code, qua C#, that is worth mentioning. It is not encapsulated. Let's start with the most obvious one. A bank account has a password, and you are supposed to provide the right password in order to get information from it. Your interface *reveals* the password, so malicious code can do var pass = theBankAccount.password; and then provide the password back. What's needed is something like var balance = theBankAccount.queryBalance(pass); where passwords go *in* to theBankAccount but never ever ever come *out*. Another thing is that a BankAccount belongs to a specific Customer. There's a good way and a bad way to manage this. The bad way is for the caller to create a new account that belongs to nobody, and then *tell* the Customer "here is a new account". With this interface, you could tell any number of Customers that they own the account. That's possible in the real world, but in the challenge, it isn't. The good way is to *ask* the Customer "please create a new account and tell me what it is", and have no way to force a Customer to accept an account willy nilly. That way a Customer can be certain that the accounts it is holding belong to it and it alone. Or it could be were it not for a major encapsulation issue. The idea of encapsulation is that EVERY CHANGE TO AN OBJECT'S STATE MUST BE MADE BY THAT OBJECT including the start of owned containers. In Java, for example, you might have public class Customer { private final ArrayList<Account> accounts = new ArrayList<Account>(); ... public List<Account> getAccounts() { return Collections.unmodifiableList(accounts); } ... public Account newAccount(...details...) { final Account a = new Account(...details...'); accounts.add(a); return a; } ... } If you are going to provide access to a collection, (1) make the collection immutable in the first place, or (2) return an immutable view of it, or (3) best of all, DON'T provide access to the collection but provide queries that extract just the information you want to make available. This has nothing to do with Java or Smalltalk or C# as such; encapsulation is object-oriented-programming 102. For what it's worth, I used to be a University lecturer, and it was MUCH harder for students to grasp encapsulation than to grasp recursion. I have no idea why. Just pretend that you are a nice little object surrounded by malevolent pranksters who can force you to do anything in your interface, and make sure they cannot harm you. Oh, when I asked about the source of the challenge, what I was getting at was "is this your paraphrase of the challenge, in which case please tell us to find the original, or is this the actual unmodified original text, in which case --ing h---, you have my profound sympathy." This looks like a garbled version of an exercise that I did a little over 10 years ago, which I found in a Java-based book whose details I unfortunately forgot to record. Right down to the names of the classes! That is why I am pretty sure that there is a description of the problem somewhere that makes sense.

Aug. 17, 2019

Re: [Pharo-users] Why do I not see the transactions when opening a customer

by Roelof Wobben

Aug. 17, 2019

Re: [Pharo-users] Why do I not see the transactions when opening a customer

by Richard O'Keefe

What is the source of the challenge? Is there a version in English? I am having very serious trouble trying to make sense of "your bank accounts can have multiple accounts for money". I note that in your C# code a customer has an ID, a first name, and a last name. There is nothing about this in the challenge text, and since some people have one-part names, I have a three- part name, and my father had and my grand-daughter has four-part names, I should think that simply representing a name as a string without caring about subdivisions would be better. What I'm getting at is this: with a specification like that, how will you know when your code is correct?

Aug. 17, 2019

Re: [Pharo-users] Why do I not see the transactions when opening a customer

by Richard O'Keefe

What did you expect transaction = Transactions new. to do, besides computing the answer 'false' and throwing it away? On Fri, 16 Aug 2019 at 22:38, Roelof Wobben <r.wobben(a)home.nl> wrote: > Hello, > > I try now to make this challege work on Pharo which is orginal a c# > problem to practice OOP. > > The challenge is this : > > Consider the following situation: > You have a bank account. Bank account has a password which is hidden and you can access data within bank > account only by providing the right credentials. > Bank acount has a whole bunch of transaction history. > Transaction is basically a record with name, description, amount (either positive or negative) > and specific account linked to it (your bank accounts can have multiple accounts for money). > > You need to: ask each user for credentials and output how much money do they have in each bank account. > > Classes: Customer, Transaction, BankAccount. > > So far I have this : https://github.com/rwobben/bankaccount > > but when I do this on playground: > > customer := Customer new. > bankAccount := Bankaccounts new. > bankAccount password: 'secret'. > customer AddBankAccountToCustomer: bankAccount. > > transaction = Transactions new. > bankAccount addToBankAccount: transaction. > > customer. > > > and I inspect the customer I do not see the transaction addded to the bankaccounts collection. > > What do I do wrong ? > > Roelof > > > > >

Aug. 17, 2019

2 days left to submit your software to the ESUG Innovation Technology Awards

by N. Bouraqadi

Submit your project and show all the cool things enabled by Smalltalk :-) > Begin forwarded message: > > From: "N. Bouraqadi" <bouraqadi(a)gmail.com <mailto:bouraqadi@gmail.com>> > Subject: ESUG Innovation Technology Awards Call for submissions > Date: 9 July 2019 at 16:08:49 CEST > To: Board ESUG <board(a)lists.esug.org <mailto:board@lists.esug.org>>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > > Dear Smalltalkers, > > Developers are invited to submit their Smalltalk-related project to the 16th edition of the ESUG Innovation Technology Awards. > The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. > > Submit now! > > Instructions are available at: https://esug.github.io/2019-Conference/awardsCall2019.html <https://esug.github.io/2019-Conference/awardsCall2019.html> > > Noury

Aug. 16, 2019