I would argue that obj.set_enabled(true) and obj.enabled = true are semantically the same. It would be a break in the programmer's expectations if this weren't true. set/get functions are just making up for a lack of accessors/getters in a language.

Setting enabled in my scenario doesn't do something everytime. I'd never argue for that. You can safely set it repeatedly to the same value and nothing changes, only if the value changes. In declarative programming, and reactive programming though, there are a lot of dependent variables. By changing one you can set-off a cascade of modifications.

I am opposed to getters and setters entering into JavaScript. I don't like them in C# either.

I would argue that obj.set_enabled(true) and obj.enabled = true are semantically the same.

I still have to disagree on this for the reason that I have been bitten multiple times by badly designed software that hid logic inside a getter. This was not known to me until I experienced performance issues which required me to dig into the library I was using only to realize this was not a property value that I was expecting, but a full blown function disguised as a getter. If this had instead been a function, I would have expected some type of logic to be inside.

Because some people misuse a feature is a bad reason to dislike it. An idiot can just as easily write a function called get_name() that deletes your hard drive.

Valid point.

I have been stung by this before, so I definitely hold a bias. I also prefer functional designs over OOP, so there is a lot of OOP that I also dislike.

code of conduct - report abuse