On Thu, Jul 2, 2020 at 9:48 PM Steven Blenkinsop <steven...@gmail.com> wrote:
>
> Another option for abstracting over builtin and custom type cases would be to
> add namespaced extension methods. Basically, a package could add methods to a
> builtin type which are namespaced by the package, and then interfaces could
> qualify their method names with the particular package whose methods they
> want to use. Downstream packages would be able to satisfy these methods only
> for the types they define, like with normal "free" methods. This change would
> potentially have a far reaching impact, but it would sidestep needing to add
> a lot of names to the language.
>
> type CustomOrdered(type T) interface {
> package.Less(other T) bool
> }
>
> func (x int) package.Less(y int) bool {
> return x < y
> }
>
> It would be nice if you could do this for all types that implement
> constraints.Ordered in one definition, but that's a whole other can of worms.
The trick with this kind of approach is understanding what should
happen if the type with a package-specified method is converted to an
empty interface type, handed to some other package, and then in some
way handed back to the original package. Does the package-specified
method survive these conversions? Why or why not? Also, how does
type reflection work: can it discover such methods? Can it discover
them in a different package? There may be answers here but they don't
jump out as obvious.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXr5%2BSczr7cx6gwY0tOiErXerG9p2Nk__kB8GwShdrpXg%40mail.gmail.com.
