2013/10/3 Mark S. Miller <erights@google.com> > It's not just property getting and setting. Your Map and Set examples are > special cases of the more general issue. In order to do a readonly facet of > an abstraction, you have to know what public methods of the underlying > abstraction are pure query methods vs potentially mutating methods. This > knowledge is not represented in any generic form, and so this faceting > can't be built as a generic proxying abstraction. You have to build > type-specific facets. You could express those facets with proxies, but > there's no reason to. > Type-specific facets would reintroduce the maintenance hazards that Tab was trying to avoid though. But you're absolutely right about the need for labeling individual methods as query methods vs mutators, if you want to build any kind of generic read-only facet. If all query methods were explicitly labeled, then a proxy-based solution could work, if the built-ins can be made to recognize read-only proxies for their type. A built-in getter would then unwrap the read-only proxy, while a built-in setter would throw when applied to a read-only proxy. If read-only refs can only be constructed for interfaces marked [ReadOnlyCapable], you only need to make built-ins marked with this attribute aware of potential read-only references. That said, you need to weigh the benefit of a generic proxy-based solution (less interface duplication) against the increase in complexity. Not sure whether the gain is worth the pain in this case. Regards, Tom
Received on Thursday, 3 October 2013 08:08:43 UTC