Marshall schrieb: > What about my example of SQL? Mutation, no pointers, no aliasing. > Yet: useful.
Sorry, but SQL does have aliasing. E.g. if you have records that have name="John", surname="Doe", the statements SELECT * FROM persons WHERE name = "John" and SELECT * FROM persons WHERE name = "Doe" are aliases of each other. The alias is actually in the WHERE clause. And this *can* get you into trouble if you have something that does UPDATE ... WHERE name = "John" and UPDATE ... WHERE surname = "Doe" e.g. doing something with the Johns, then updating the names of all Does, and finally restoring the Johns (but not recognizing that changing the names of all Does might have changed your set of Johns). Conceptually, this is just the same as having two different access path to the same memory cell. Or accessing the same global variable through a call-by-reference parameter and via its global name. BTW with views, you get not just aliasing but what makes aliasing really dangerous. Without views, you can simply survey all the queries that you are working with and lexically compare table and field names to see whether there's aliasing. With views, the names that you see in a lexical scope are not enough to determine aliasing. E.g. if you use a view that builds upon the set of Johns but aren't aware of that (possibly due to abstraction barriers), and you change the name field of all Does, then you're altering the view without a chance to locally catch the bug. That's just as bad as with any pointer aliasing problem. Regards, Jo -- http://mail.python.org/mailman/listinfo/python-list