There was a similar proposal before. Some people insist that there should
be a clear separation between state and behavior. Struct is for state and
interface is for behavior.
I too was toying with a similar idea before. My reasoning has less to do
with trying to fit into an interface, but it was more about about the
flexibility of changing the struct's data implementation. Let's say you
have a struct with exposed fields. Then one day you need to add more
behavior into the struct. However, to accommodate that behavior you need to
change the struct's data implementation. It is not possible to do that if
the struct already has exposed fields. One solution is to create a separate
struct. The other is with properties as you mentioned.
I was thinking about submitting a proposal, but I changed my mind. The more
I think about it, the more I am convinced that it is not necessary. None of
the problems would have occurred if you stick to modern programming
practices of using getters and setters, instead of exposed fields. Some
people loath modern programming practices, and start doing things the
opposite way. Granted that there are people who abuse such practices and
give modern programming a bad rep, I would think that unless you have a
very good reason, it is better to stick to the conventional wisdom. Note
that modern programming also recognize the existence of data objects (such
as DTO), where you can just have a plain struct with exposed fields.
On Saturday, September 29, 2018 at 5:45:32 AM UTC+7, Peter Müller wrote:
>
> The other day I had an interesting idea: What if all exported fields have
> an implicit getter. Like e.g.
>
> type Human struct {
> Age uint
> Name string
> }
>
> would implicitly get the methods:
>
> func (h Human) Name() string {
> return h.Name
> }
> func (h Human) Age() uint {
> return h.Age
> }
>
>
> *When defining an interface*
>
> type Being interface {
> Age() uint
> Name() string
> }
>
> getters would not have to be defined if they simply return a property.
> This would remove boilerplate code. But if a modification or calculation is
> needed you would just make a private property and define a custom getter.
>
>
> *Backwards compatibility*
>
> Explicitly defined getters would be overriding the implicit ones and
> therefore not change behaviour of existing programs.
>
>
>
> This is only an idea. I post this to know if either this is a valid idea
> worth considering putting into go or if there is just something wrong with
> my style of coding and using interfaces.
>
--
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.
