> Some bit of reflection magic which allowed objects to remove methods from their method sets at runtime would be perfect. You'd just use interface upgrades and

> Some bit of reflection magic which allowed objects to remove methods from their method sets at runtime would be perfect. You'd just use interface upgrades and you'd be sure that it would work. Given that methods sets are...sets. I'd be interested at a language level, what it would look like to add some notion of set difference or expressing disjointedness in some way, e.g., type ReadOnly retraction { Write([]byte) (int, error) } type ReadOnlyFile struct { ReadOnly *File } where `ReadOnlyFile` would have all of `*File`'s methods minus the methods defined in `ReadOnly` restriction probably isn't a good term, I could see it easily being misinterpreted, but I haven't all day to ponder it :) (edit: after publishing I realized `retract` might be more clear) I don't know if it would ultimately simplify the problem or not, but I agree that having some way to easily mask or hide a method subset could be quite nice. Edit: I want to add that the idiomatic thing to do now would be type ReadOnlyFile File / *proceed to implement every method you want accessible */ maybe something like the following could be possible type ReadOnlyFile retracts *File { Write([]byte) (int, error) }