Magnus Lycka <[EMAIL PROTECTED]> wrote: ... > > I think you mean volatile or mutable rather than transient? "transient" ... > Right, volatile it is. It's really great that I can program so much > Python now that I forget my C++! :) Thanks Alex (both for reminding me > of forgotten C++ syntax and for making Python better).
Heh, you're welcome. Hadn't done anything much with C++ for almost five years, but found out (to my surprise, wouldn't have predicted it!) that it all comes back to me effortlessly (I might put it down to working with Matt Austern, but what we did together at Google wasn't C++...;-). My _perl_, OTOH, *has* gone all fuzzy... go figure! (Guess I have a C++-shaped mind rather than a perl-shaped one, FWIW:-). > I've run into a lot of cases where things are conceptually non-mutating, > but in implementation, there are lots of internal state changes. For Sure, caching and "just in time" computation are common. That is basically the difference between interface and implementation, and the distinction in C++ between "logically const" and "physically const" (but that doesn't really work right, either, for different reasons). > While simple "warning signs" might be useful at times, I find that > the devil is in the details, and most programming problems are too > subtle to be described with an exclamation mark. "Problems", yes; method names, not necessarily. Being able to assert that X==X' (using the X' notation to mean "X before the call") does have expressive power; this leaves all the needed leeway to change implementation as long as it touches "hidden" state only. Thread safety and atomicity are really quite different issues, just like for any class invariant. If there's a class invariant P(), that means that P(X') [before the call] and P(X) [after it] both hold, but the word "invariant" does *NOT* mean that P holds "invariably" DURING the execution of X's methods, so class invariants cannot be used to infer threadsafety, much less atomicity -- that would constrain the implementation of the method WAY too much in the general case. (_Callbacks_ from a method to generic callables passed from the outside can be a headache -- there's no general theory as to what should hold while an external callback executes... though I'm in the camp claiming that invariants SHOULD hold at that time, I understand the debate). I don't think these headaches and difficulties justify dumping the whole field of reasoning about programs, nor the subfield of PbC. The concept of "immutable" is really just a tiny corner of these fields, and it's a long way from being the hardest or most problematic one in them;-). Alex -- http://mail.python.org/mailman/listinfo/python-list