11-Oct-2013 18:46, Joseph Rushton Wakeling пишет:
On 11/10/13 16:32, Dmitry Olshansky wrote:
This. And exactly the same for immutable. It's interesting how folks
totally
expect complex types (like containers) to meaningfully work with all 3
qualifiers.
It's not so much that we expect it, as that we might expect that
standard library types would _have the appropriate design work put in_
so that they would "just work" with these qualifiers. (Admittedly
shared is a bit of a special case right now that probably needs more
work before support is rolled out.)
It can't - it's like expecting 37 to modify an become 76.
Simply put built-ins are special. Imagine a ref-counted type - how would
you copy it (and increment a count) with bit-wise immutability?
It simply doesn't make sense. (Yes, one can keep count elsewhere e.g. in
a global hash-table).
More importantly there is little incentive to make immutable stuff
ref-counted, especially COW-types. In this sense BigInt simply doesn't
work with immutable by design, if need be one can make FixedBigInt that
doesn't include COW, doesn't support read-modify-write and mixes well
with BigInt.
Immutable works best as static data and/or as snapshot style data
structures. It's tables, strings and some unique stuff that gets frozen
and published at a certain point (usually at start up).
It makes a lot less sense at local scope aside from aesthetic beauty as
there is plenty of invariants to check, and bitwise immutability is a
minority of that.
I would even suggest to adopt a convention for a pair of freeze/thaw
methods for any UDT that give you a deep copy of object this is made for
mutation (thaw on immutable object) or immutable (freeze mutable).
If you tell me that's an unreasonable expectation then fair enough, but
it feels pretty bad if e.g. library-implemented number types (big
integers or floats, rationals, complex numbers, ...) can't from a user
perspective behave exactly like their built-in counterparts.
No magic paint would automatically expel reference count from the
struct's body. With shared it's even more obvious.
In general user defined type has to be designed with one of 3 major use
cases in mind: local, immutable, shared.
--
Dmitry Olshansky
