Re: Figuring out easier readonly interfaces

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