4 ms·

The main problem the method pointers solves for me is answering the question "can this object do X". The mere existence of a method you can type assert isn't en

by nickcw 2y ago

The main problem the method pointers solves for me is answering the question "can this object do X". The mere existence of a method you can type assert isn't enough. Returning a NotImplemented error isn't a great solution either as you might have to do quite a bit of work to get ready to call the method only to find it isn't implemented. 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. Also an available flag for each method would work too and might be neater than the function pointers.

chrsig 2y ago
> 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) }
folays 2y ago
A similarity to your struct of fileops, would be Go to allow implementing an interface will nil methods. Like: func (f *file) Rename() = nil Then later test for nilness with: if f.Rename == nil, or with better readability: if v, ok := f.(interface {Rename()}); ok && v == nil // -> if true, then nil method We could define a Type Assertion to return "nil, ok" when all methods of the interface it is being passed to are implemented nil methods. type NotOftenImplemented interface { RareMethod() SuperRareMethod() } if v, ok := data.(NotOftenImplemented); ok && v == nil { // RareMethod() and SuperRareMethod() are nil } switch data.(type) { case NotOftenImplemented: // would be supposed to match ONLY if AT LEAST >= 1 of the methods of this interface is non-nil } Of course it would create a phenomenon where all callers of any interface methods would now fear of calling any method without first testing for its nillness. On another hand, there is also sometimes methods implemented with a single-line of panic("Not Yet Implemented") so...

by nickcw 2y ago

chrsig 2y ago

> 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) }

folays 2y ago

A similarity to your struct of fileops, would be Go to allow implementing an interface will nil methods. Like: func (f *file) Rename() = nil Then later test for nilness with: if f.Rename == nil, or with better readability: if v, ok := f.(interface {Rename()}); ok && v == nil // -> if true, then nil method We could define a Type Assertion to return "nil, ok" when all methods of the interface it is being passed to are implemented nil methods. type NotOftenImplemented interface { RareMethod() SuperRareMethod() } if v, ok := data.(NotOftenImplemented); ok && v == nil { // RareMethod() and SuperRareMethod() are nil } switch data.(type) { case NotOftenImplemented: // would be supposed to match ONLY if AT LEAST >= 1 of the methods of this interface is non-nil } Of course it would create a phenomenon where all callers of any interface methods would now fear of calling any method without first testing for its nillness. On another hand, there is also sometimes methods implemented with a single-line of panic("Not Yet Implemented") so...