3 ms·
X.a() then X.b() may be completely different to X.b() then X.a(). This implied ordering is not really expressed anywhere. Oh noz! OO is capable of CORRECTLY m
by tjic 17y ago
X.a() then X.b() may be completely different to X.b() then X.a(). This implied ordering is not really expressed anywhere.
Oh noz!
OO is capable of CORRECTLY modeling complicated real life objects like Rubik's Cubes, cars, clothes, and vending machines...
Why is it a failure that depositing $100 to a new checking account, then writing a $90 check does a different thing than writing a $90 check against an empty checking account, then depositing cash after the check has bounced?
- apotheon 17y agoI think the problem the author has (but fails to articulate well) is that the variance in consequences of doing things in different orders is not explicit. In short, it's like you are never allowed to know what the balance of your account is until you overdraw it. Of course, I'm not sure whether that's a valid complaint either, since one can always define accessor/getter methods (e.g., "get_balance" for the checking account), but there are those who would argue that accessor methods violate the data protection principle of object oriented programming.
- gloob 17y agoBecause mutable state is an airy-fairy concept that has no relation to the world, of course.