December 2019 - Pharo-users

Re: [Pharo-users] can I write this without the three if then;s

by ponyatov

What Smalltalk has for full-sized pattern matching? Is it possible to make in message-only syntax? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 30, 2019

Re: [Pharo-users] can I write this without the three if then;s

by Richard Sargent

Pharo Smalltalk Users mailing list wrote > Hello, > > Im trying to solve a challenge from exercism whereÂ I have to > calculate the points somehow gets on a very simple darts board. > > I solved it like this : > > > scoreX: anInteger y: anInteger2 > Â Â Â | distance | > Â Â Â distance := (anInteger squared + anInteger2 squared) sqrt. > Â Â Â distance > 10 > Â Â Â Â Â Â ifTrue: [ ^ 0 ]. > Â Â Â distance > 5 > Â Â Â Â Â Â ifTrue: [ ^ 1 ]. > Â Â Â distance > 1 > Â Â Â Â Â Â ifTrue: [ ^ 5 ]. > Â Â Â ^ 10 > > > but now I use three if then and I think it's ugly code. > > Is there a way I can make it more the smalltalk way ? Roelof, this example is too simple to "really do it the Smalltalk way". In a more realistic scenario, you would have classes for each "rule" with corresponding differences in behaviour. In the above example, you could get away with a single class with two instance variables and configure three instances of it appropriately. In more complex scenarios, your start up code instantiates the various rules, with precedence determined by the order of the rule instances. Then when you need to determine which rule to apply, you use #detect:ifNone: to find the rule that applies with the #ifNone: block providing the fallback result. Sometimes, you work with classes themselves to determine which class to use, but I have described working with instances for the general concept. (After all, classes are instances.) Using rules with a #select: allows you to handle a scenario where multiple rules apply. A good example is rules to provide the default coverages for an auto insurance policy, where each possible coverage can have one or more rules to assess the many characteristics of the applicants and so determine the one rule that applies for each possible coverage. (And yes, it is reasonable that a possible coverage has no rule applicable, in which case the coverage is not included in the default offering.) As mentioned, you /could/ apply this to your scenario, as an exercise. You might be tempted to utilize an existing class with two instance variables. That would be a bad design practice, but reasonable for a /disposable/ experiment to quickly study how it works. Always (create and) use classes which truly reflect their purpose and have named properties which truly reflect the objects they hold. In your scenario, #distance and #score seem appropriate. > > Regards, > > Roelof -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 30, 2019

Re: [Pharo-users] Date offset in Glorp and RDBMS

by eftomi

Actually, the issue was with reading the variant Date and creating a DateAndTime object by directly setting the JulianDayNumber without respect to the timezone. I commited the necessary change to PharoCOM <https://github.com/tesonep/pharo-com> . -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 29, 2019

Re: [Pharo-users] Date offset in Glorp and RDBMS

by eftomi

Thanks for the clues! At first glance, I'd say that the testing could be changed into #equals since the majority of date related tests are not focused into timezones - for instance, one of these tests is GlorpObjectMappedToImaginaryTableTest>>#testReadBackEntireExample which sends #assertEqual: to subclass of GlorpTestModelClasses. These #assertEqual: methods look like GlorpVideoCreditStatus>>#assertEqual: aCreditStatus self assert: customer name = aCreditStatus customer name. self assert: customer dateOfBirth = aCreditStatus customer dateOfBirth. self assert: balanceOwing = aCreditStatus balanceOwing. self assert: dateOwing = aCreditStatus dateOwing. self assert: comments = aCreditStatus comments. There might be some specific test on timezones, though, Glorp has a huge testing package. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 29, 2019

Re: [Pharo-users] Date offset in Glorp and RDBMS

by Esteban Maringolo

+1 to #equals:, it is for that purpose. However it might be the case that Glorp is testing a type that is expected to have an offset/timezone, in which case you'd be "eating" the error if the cell value contains a timezone different than the one in your image. Esteban A. Maringolo On Sun, Dec 29, 2019 at 9:46 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Tomaz, > > Consider > > DateAndTime now asUTC asDate = Date today. > > which is false (on most systems), while > > DateAndTime now asUTC asDate equals: Date today. > > is true. #equals was added specifically for that purpose (ignore the offset). > > Note also that an abstract date (year/month/day) does not exist without the context of a proper timezone (an offset is not enough). > > Sven > > > On 29 Dec 2019, at 13:29, eftomi <tomaz.turk(a)ef.uni-lj.si> wrote: > > > > Dear all, > > > > Going through the remaining red tests in PharoADO + Glorp, I have a sort of > > a conceptual challenge. Some of the Glorp tests are checking the equality of > > dates written to and then returned from the database. Pharo regards the > > dates as not equal if their time offsets are different despite the fact that > > the date (in a narrow sense) is the same. For instance: > > > > "2019-12-29T00:00:00+01:00" > > > > is not equal to > > > > "2019-12-29T00:00:00+00:00" > > > > The challenge is that the ActiveX Data Objects (ADO) library that I'm using > > returnes the dates in Variants which don't have any information about the > > offset. The conversion from ADO variants to Pharo's Date is done in PharoCOM > > package. > > > > What would be the best approach to somehow ignore the missing offset or > > impute a proper value? Of course it's better to ignore a missing data than > > to impute a wrong value. How is this handled with other DB systems? > > > > Thanks, > > Tomaz > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > >

Dec. 29, 2019

Re: [Pharo-users] can I write this without the three if then;s

by Esteban Lorenzano

The âKent Beck approved solutionsâ here are two: 1) To use a dictionary (or ordered dictionary). case := OrderedDictionary newFromPairs: { [ cond ]. [ do ]. [ cond ]. [ do ]. [ true ]. [ otherwise do ] } case keysAndValuesDo: [ :cond :do | (cond value: expression) ifTrue: [ âyou need to break here" ^ do value ]. 2) To use a âcase methodâ caseMethod: expression expression = cond1 ifTrue: [ ^ do1 ]. expression = cond2 ifTrue: [ ^ do2 ]. ^ otherwise Personally, I prefer the second one because is more concise, performant and easy to understand. Esteban > On 28 Dec 2019, at 11:58, Dennis Schetinin <chaetal(a)gmail.com> wrote: > > It would be an overkill to do it for this particular case, but Smalltalk makes it possible to implement a case-like construction: > > [ expression ] > when: [ :value | condition1 ] do: [-0do :value | ... ]; > when: [ :value | condition2 ] do: [ :value | ... ]; > otherwiseDo: [ :value | ... ]; > evaluate > > > I am sure, something like this has been implemented already somewhere (maybe in Squeak?). Still not sure it is practical as compared to simple if-s, and for sure not widely used :) > ...On the other hand, sometimes the case-like construction can be considered a more intension-revealing style. > > Ð¿Ñ, 27 Ð´ÐµÐº. 2019 Ð³., 22:18 Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>>: > Hello, > > Im trying to solve a challenge from exercism where I have to calculate the points somehow gets on a very simple darts board. > > I solved it like this : > > > scoreX: anInteger y: anInteger2 > | distance | > distance := (anInteger squared + anInteger2 squared) sqrt. > distance > 10 > ifTrue: [ ^ 0 ]. > distance > 5 > ifTrue: [ ^ 1 ]. > distance > 1 > ifTrue: [ ^ 5 ]. > ^ 10 > > > but now I use three if then and I think it's ugly code. > > Is there a way I can make it more the smalltalk way ? > > > Regards, > > Roelof >

Dec. 29, 2019

Re: [Pharo-users] Date offset in Glorp and RDBMS

by Sven Van Caekenberghe

Hi Tomaz, Consider DateAndTime now asUTC asDate = Date today. which is false (on most systems), while DateAndTime now asUTC asDate equals: Date today. is true. #equals was added specifically for that purpose (ignore the offset). Note also that an abstract date (year/month/day) does not exist without the context of a proper timezone (an offset is not enough). Sven > On 29 Dec 2019, at 13:29, eftomi <tomaz.turk(a)ef.uni-lj.si> wrote: > > Dear all, > > Going through the remaining red tests in PharoADO + Glorp, I have a sort of > a conceptual challenge. Some of the Glorp tests are checking the equality of > dates written to and then returned from the database. Pharo regards the > dates as not equal if their time offsets are different despite the fact that > the date (in a narrow sense) is the same. For instance: > > "2019-12-29T00:00:00+01:00" > > is not equal to > > "2019-12-29T00:00:00+00:00" > > The challenge is that the ActiveX Data Objects (ADO) library that I'm using > returnes the dates in Variants which don't have any information about the > offset. The conversion from ADO variants to Pharo's Date is done in PharoCOM > package. > > What would be the best approach to somehow ignore the missing offset or > impute a proper value? Of course it's better to ignore a missing data than > to impute a wrong value. How is this handled with other DB systems? > > Thanks, > Tomaz > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Dec. 29, 2019

Date offset in Glorp and RDBMS

by eftomi

Dear all, Going through the remaining red tests in PharoADO + Glorp, I have a sort of a conceptual challenge. Some of the Glorp tests are checking the equality of dates written to and then returned from the database. Pharo regards the dates as not equal if their time offsets are different despite the fact that the date (in a narrow sense) is the same. For instance: "2019-12-29T00:00:00+01:00" is not equal to "2019-12-29T00:00:00+00:00" The challenge is that the ActiveX Data Objects (ADO) library that I'm using returnes the dates in Variants which don't have any information about the offset. The conversion from ADO variants to Pharo's Date is done in PharoCOM package. What would be the best approach to somehow ignore the missing offset or impute a proper value? Of course it's better to ignore a missing data than to impute a wrong value. How is this handled with other DB systems? Thanks, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 29, 2019

Re: [Pharo-users] Hi Community

by Petter

Hei Pablo and thanks for an interesting project. I liked the feature that you can write code as actually code ð -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 29, 2019

Re: [Pharo-users] how to change data on real data but not on test data

by Roelof Wobben

Dec. 28, 2019