December 2016 - Pharo-users

Re: [Pharo-users] Modeling a join table

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

Are you going to use relational database to store this data? Or you goint to use image saving / object-oriented DB for persistence? Than, can you please describe your task / domain model with more details? Particularly: 1) Are there strong asymmetry in queries? Which kind of queries are more frequent: "give me tags of this radio" or "give me radios with this tag"? 2) Do you need to store other information EXCEPT fact that that radio is marked by this tag? For example, do you need to store the time tag was assigned to the station or the user who have assigned it? You got the idea, I believe. 3) Are queries simple "stations with tag X" / "tags of station X", or they may often looks like "stations with tag A or B, but not both" or something even more complicated. Best approach is strongly depends on the answers. "By default", however, I will make Station with collection of Tags as the "main information storage". And I will make some kind of "request" when asked about list of station with some tag. Cache this result, if needed for performance. But if you plan to use relational persistence backend, than collections on the either side will be the good idea. And you can use GLORP quite easy for this. 2016-12-13 23:59 GMT+03:00 sergio ruiz <sergio.rrd(a)gmail.com>: > Hello, all. > > This question is not as much a question about smalltalk as one about > modeling in smalltalk. > > I am currently writing an API using Teapot that will be serving up data > about internet radio stations. I want to be able to let users tag the > stations with arbitrary tags. Using a relational database, I would create > an object like "Tagging" with foreign keys pointing to the "Stations" class > and the "Tag" Class. It would have station_id and tag_id. > > If this was going to be even a tiny bit more complex, I would probably > just make it a polymorphic association. > > My question is, how would I approach this in smalltalk? Would I just make > methods on tag and station (and whatever else) that stored arrays of each > other? Would I create an intermediary model like "Tagging" and have that do > the heavy lifting? > > Ideas? Thanks!; > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com > http://www.ThoseOptimizeGuys.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Denis Kudriashov

2016-12-18 20:19 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> What is the main difference between proposed MissingValue and >> UndefinedObject? > > > MissingValue you will set up according to your business logic. While nil > is just default value of variable which could be in your object by some > incident, bug of application. And it makes impossible to distinguish bug from normal application state related to missing value

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Denis Kudriashov

2016-12-18 19:43 GMT+01:00 Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com>: > Sorry, I'm not sure I fully understand your idea. > It looks like trying to make another implementation of UndefinedObject, is > it? > > What is the main difference between proposed MissingValue and > UndefinedObject? MissingValue you will set up according to your business logic. While nil is just default value of variable which could be in your object by some incident, bug of application.

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

Sorry, I'm not sure I fully understand your idea. It looks like trying to make another implementation of UndefinedObject, is it? What is the main difference between proposed MissingValue and UndefinedObject? It's just UndefinedObject is "too system" to intervene? Or something else? 2016-12-18 18:12 GMT+03:00 Ben Coman <btc(a)openinworld.com>: > Thanks for sharing. A similar thing might be useful for dealing with > "quality" of Process Variable measurement in industrial situations - > where instruments fail from time to time. > > I'm not sure of all the pros and cons, but btw an alternative to > hanging special behaviour on a method, would be to hang special > behaviour on a MissingValue class that you could #initialize any > instance variable to. > > Object subclass: #MissingValue > instanceVariableNames: '' > classVariableNames: '' > package: 'AAAA' > > MissingValue >> * dummyValue > self inform: 'debug trace - got here'. > ^self > > MissingValue >> adaptToNumber: rcvr andSend: selector > ^self perform: selector with: rcvr > > Collection >> sumProtected > ^ self > inject: 0 > into: [ :sum :each | sum + each value] > > Usage... > > c := {1.1 * MissingValue new. 1.2 * 10. MissingValue new * 1.3. 10 * > 1.4}. > "==> an Array(aMissingValue 12.0 aMissingValue 14.0)" > > c sumExcludeMissing > "==> 26.0" > > cheers -ben > > On Sun, Dec 18, 2016 at 6:45 PM, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> > wrote: > > Imagine, you have some object with amount and price variables. > > And you want to calculate total, put this totals to collection and > calculate > > grand total. > > > > Naive implementation will be something like > > total := amount * price for the first task > > and something like > > grandTotal := totals sum for the latter one. > > > > But what if amount or price are nil's? > > You can add nil checks, of course: total := (amount ifNil:[0]) * (price > > ifNil: [0]). > > And then what if totals will be empty? More checks. > > Is it really wise to have total to be zero if amount is nil? More > > ifTrue:ifFalse: code. > > And then you want to add amount := total / price calculation, and you > > realize that both total and price may be nil, and price may be zero. > > More and more and more checks. > > > > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds > > "protected" versions of common operators and methods. > > > > So, you just put > > total := amount *@ price > > and > > grandTotal := totals sum_protected > > into your code - and everything just works. > > > > total will be nil if any of the operands are nil. grandTotal will be > > calculated normally, even for empty totals collection (will return nil > for > > empty collection). > > Collection can hold nil's and it will work anyway. If all elements of the > > collection is nil, result will be nil. > > > > Protected version of addition and subtraction will treat nil's as zeros > > until both operands are nil - then it will return nil. > > There are protected versions of comparisions, too. > > > > It's quite simple idea, which is still very useful, and it makes code > much > > more readable, clean and self-commenting. > > > > That's why I have extracted this part of SmallPOS framework, and have > > published it as separate package to use it in other, non-SmallPOS > > applications. > >

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

Thank you, Esteban! You may believe me or not, but I dream about going to every ESUG conference every time. It's not framework this time, it's just small and simple package. And it makes life much, MUCH easier when developing business applications. 2016-12-18 15:39 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi Yuri, > > Long time not seeing you ! welcome back :) > Nice framework ! > > Esteban > > On 18 Dec 2016, at 11:45, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and > calculate grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price > ifNil: [0]). > And then what if totals will be empty? *More checks*. > Is it really wise to have total to be zero if amount is nil? *More > ifTrue:ifFalse: code*. > And then you want to add amount := total / price calculation, and you > realize that both total and price may be nil, and price may be zero. > *More and more and more checks.* > > *Protego* (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds > "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything *just works*. > > total will be nil if any of the operands are nil. grandTotal will be > calculated normally, even for empty totals collection (will return nil > for empty collection). > Collection can hold nil's and it will work anyway. If all elements of the > collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros > until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code much > more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have > published it as separate package to use it in other, non-SmallPOS > applications. > > >

Dec. 18, 2016

Re: [Pharo-users] Hash collision

by stepharong

Hi andres I did not follow the discussion. My remark is just that a good discussion without code for integration does not improve Pharo and we will have people facing again the problem. Stef On Sun, 18 Dec 2016 11:29:11 +0100, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > The primitive and the primitive failure code should behave the same? > > On 12/18/16 2:13 , stepharong wrote: >> Sorry but how can we improve the situation concretely >> >> >> Stef >> >> On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net> wrote: >> >>> Oh, ok... then the failure code isn't doing what was intended :). >>> >>> On 12/13/16 15:16 , Martin McClure wrote: >>>> On 12/13/2016 08:39 AM, Andres Valloud wrote: >>>>> I would have expected the floats to be a byte object of size 8. Why >>>>> is >>>>> this conversion needed? Is somehow the primitive thinking the float >>>>> has >>>>> size 2? Or is the primitive hashing 32 bits at a time? The prim >>>>> used >>>>> to be a C version of the byte oriented 1644525 multiplicative hash, >>>>> did >>>>> this change? >>>> >>>> The float is not a byte object of size 8, it's a word object of size >>>> 2. >>>> >>>> When you feed it to #hashBytes:startingWith: the primitive fails. (I >>>> didn't look at why -- maybe because it isn't a byte object?) >>>> >>>> The alternative Smalltalk code treats it like it was a byte object, >>>> even >>>> though it's not. So it iterates through the two words, multiplying >>>> each >>>> by 1664525, then keeping only the low-order 28 bits of the result. But >>>> since each word is a full 32 bits, the high-order four bits of each >>>> word, which include the sign bit, can never affect the hash. >>>> >>>> Regards, >>>> >>>> -Martin >>>> >>> >> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by stepharong

thanks for sharing it with us. Now in Moose we have metrics and when a metrics value is not available giving 0 is not the solution. We should probably have Value that wraps the real value for normal case and Unvalued for the case where there is no value. Stef On Sun, 18 Dec 2016 11:45:30 +0100, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and > calculate grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price > ifNil: [0]). > And then what if totals will be empty? More checks. > Is it really wise to have total to be zero if amount is nil? More > ifTrue:ifFalse: code. > And then you want to add amount := total / price calculation, and you > realize that both total and price may be nil, and price may be zero. > More and more and more checks. > > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds > "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything just works. > > total will be nil if any of the operands are nil. grandTotal will be > calculated normally, even for empty totals collection (will return nil > for empty collection). > Collection can hold nil's and it will work anyway. If all elements of > the collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros > until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code > much more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have > published it as separate package to use it in other, non-SmallPOS > applications. -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Ben Coman

Thanks for sharing. A similar thing might be useful for dealing with "quality" of Process Variable measurement in industrial situations - where instruments fail from time to time. I'm not sure of all the pros and cons, but btw an alternative to hanging special behaviour on a method, would be to hang special behaviour on a MissingValue class that you could #initialize any instance variable to. Object subclass: #MissingValue instanceVariableNames: '' classVariableNames: '' package: 'AAAA' MissingValue >> * dummyValue self inform: 'debug trace - got here'. ^self MissingValue >> adaptToNumber: rcvr andSend: selector ^self perform: selector with: rcvr Collection >> sumProtected ^ self inject: 0 into: [ :sum :each | sum + each value] Usage... c := {1.1 * MissingValue new. 1.2 * 10. MissingValue new * 1.3. 10 * 1.4}. "==> an Array(aMissingValue 12.0 aMissingValue 14.0)" c sumExcludeMissing "==> 26.0" cheers -ben On Sun, Dec 18, 2016 at 6:45 PM, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and calculate > grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price > ifNil: [0]). > And then what if totals will be empty? More checks. > Is it really wise to have total to be zero if amount is nil? More > ifTrue:ifFalse: code. > And then you want to add amount := total / price calculation, and you > realize that both total and price may be nil, and price may be zero. > More and more and more checks. > > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds > "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything just works. > > total will be nil if any of the operands are nil. grandTotal will be > calculated normally, even for empty totals collection (will return nil for > empty collection). > Collection can hold nil's and it will work anyway. If all elements of the > collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros > until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code much > more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have > published it as separate package to use it in other, non-SmallPOS > applications.

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Esteban Lorenzano

Hi Yuri, Long time not seeing you ! welcome back :) Nice framework ! Esteban > On 18 Dec 2016, at 11:45, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and calculate grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price ifNil: [0]). > And then what if totals will be empty? More checks. > Is it really wise to have total to be zero if amount is nil? More ifTrue:ifFalse: code. > And then you want to add amount := total / price calculation, and you realize that both total and price may be nil, and price may be zero. > More and more and more checks. > > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego <http://www.smalltalkhub.com/#!/~assargadon/Protego>) adds "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything just works. > > total will be nil if any of the operands are nil. grandTotal will be calculated normally, even for empty totals collection (will return nil for empty collection). > Collection can hold nil's and it will work anyway. If all elements of the collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code much more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have published it as separate package to use it in other, non-SmallPOS applications.

Dec. 18, 2016

Protego - smart way to manage NIL's in business calculations

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

Imagine, you have some object with amount and price variables. And you want to calculate total, put this totals to collection and calculate grand total. Naive implementation will be something like total := amount * price for the first task and something like grandTotal := totals sum for the latter one. But what if amount or price are nil's? You can add nil checks, of course: total := (amount ifNil:[0]) * (price ifNil: [0]). And then what if totals will be empty? *More checks*. Is it really wise to have total to be zero if amount is nil? *More ifTrue:ifFalse: code*. And then you want to add amount := total / price calculation, and you realize that both total and price may be nil, and price may be zero. *More and more and more checks.* *Protego* (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds "protected" versions of common operators and methods. So, you just put total := amount *@ price and grandTotal := totals sum_protected into your code - and everything *just works*. total will be nil if any of the operands are nil. grandTotal will be calculated normally, even for empty totals collection (will return nil for empty collection). Collection can hold nil's and it will work anyway. If all elements of the collection is nil, result will be nil. Protected version of addition and subtraction will treat nil's as zeros until both operands are nil - then it will return nil. There are protected versions of comparisions, too. It's quite simple idea, which is still very useful, and it makes code much more readable, clean and self-commenting. That's why I have extracted this part of SmallPOS framework, and have published it as separate package to use it in other, non-SmallPOS applications.

Dec. 18, 2016