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 <esteba...@gmail.com>: > Hi Yuri, > > Long time not seeing you ! welcome back :) > Nice framework ! > > Esteban > > On 18 Dec 2016, at 11:45, Юрий Мироненко <assargad...@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. > > >
