Are we talking strictly about immutable memory here? Because in the presence of memory-mutability, GC is far from "solving" modularity.
With mutability, GC does the same thing for resource-handles that it does for memory-handles -- it makes sure that if you have a managed handle, it is not going to cause an MMU fault if you access it. In *neither* case does it offer any more guarantees than that. Just like one module could close a file handle in-use by another module, one module could clear/empty a collection in use by another module. Just like one module could seek a file handle being read by another module, one module could set modal-state in a class being used by another module. It's true that the finite nature of hardware means sometimes only one client can have the resource open (if it is not virtualized). For example, one can imagine a hardware camera API, which only allows one client of the camera at a time. However, software-only modules with singletons can produce similarly limited usage patterns. Therefore, even with GC, the "informal contracts" of modules need to address many concerns, for both memory and hardware resources, including, but not limited to: (a) lifetime (avoid retaining resources too long); (b) acceptable mutability patterns; (c) thread-safety expectations; (d) state-modality expectations (e) usage/performance envelopes. With mutability, how is it that GC "solves modularity" for memory any more than for resource-handles?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
