On Apr 30, 2011, at 8:22 PM, Mariano Martinez Peck wrote: > Thanks everybody, it is nice to see I am not alone.. > Yes, Stef, the API is the same, but the sematics is not.
why? not? I'm confused. > I mean, I muuuch prefer to change it, but indeed, there will be a change in > the "behavior". What I mean is that all test cases that were using > #assert:equals: in the "correct" way (correct I mean to what SUnit says), > then after will be "incorrect". I don't care. The only problem is that when > they debugger the message will be incorrect. > But it is as always....or improve or be backward compatibility.... > > So... +1 to the change > > Here is the issue tracker: > http://code.google.com/p/pharo/issues/detail?id=4129 > > if we finally agree, I can submit the fix. > > Cheers > > Mariano > > > On Sat, Apr 30, 2011 at 7:13 PM, Damien Cassou <[email protected]> > wrote: > On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck > <[email protected]> wrote: > > testBlah > > | universalAnswer | > > universalAnswer := 30. > > universalAnswer := universalAnswer + 11. > > self assert: universalAnswer equals: 42. > > > > In this case, 42 is the "expected" and "universalAnswer" is the "actual" > > value. > > I feel weird writing like this: > > > > self assert: 42 equals: universalAnswer. > > I think I'm responsible for this non sense, sorry about that. When I > put the parameters in this order, I thought the result would be > similar to JUnit in which 'expected' is always before 'actual'. > Unfortunately, it looks like I just forgot to read the whole sentence: > 'self assert that something equals 42' reads much better than the > other way around. I don't think too much code depends on this > #assert:equals: method as it has only been introduced recently. > > I vote for changing the order. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > > > > -- > Mariano > http://marianopeck.wordpress.com >
