Ian Denhardt <i...@zenhack.net>:
> Quoting Eric S. Raymond (2018-10-19 16:03:02)
>
> > Both classes want to be selected by a field "name". It's annoying that
> > I can't declare an interface that says "has a field 'name'" and instead
> > have to declare a getter function with no other point besides sliding
> > around that restriction.
> >
> > But precisely because this could easily be patched into interfaces,
> > I think it's not much of an argument for your plan.
>
> To spell out how this would for anyone who doesn't immediately see the
> design, you could e.g. extend interfaces to be able to have fields like
> so:
>
> type HasName interface {
> Name string
> }
I think it could be simpler than that. The Name part isn't necessary;
anything that isn't a fieldname should be syntactically
distinguishable.
> I am neutral-to-against doing this, as normally when abstracting over
> something, it is a behavior, not a field. But if being able to specify
> "must have this field," is deemed necessary, I agree this is the way to
> do it.
Quite. Alas, ianlancetaylor's explanation of why this feature was rejected
is sufficient.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
--
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.
For more options, visit https://groups.google.com/d/optout.
