On a few events we have public attributes that event subscribers can modify to alter behavior. We've been back and forth on using this pattern of public properties vs method calls that wrap the property. I haven't had a strong opinion either way until now, where I am leaning towards using method calls:
1. We have complete control over the data that actually gets set on the property by using a setter/getter. So someone won't be able to set a boolean property to a string or something.
2. The API is a bit more obvious, especially in cases where we are already using getters/setters for other properties but not all of them.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | method-calls-for-api-2830620.5.patch | 11.11 KB | bkosborne |
| #2 | method-calls-for-api-2830620.patch | 11.02 KB | bkosborne |
Comments
Comment #2
bkosborneComment #3
metzlerd commentedI'm not sure about this pattern. Forcing people to call different setters for a different value seems like it will complicate the implementation code. Any reason why we don't use setCacheable(TRUE) and setCacheable(FALSE)?
Comment #4
bkosborneHmm I see your point. I'll update with a single setter.
Comment #5
bkosborneI changed the setters/getters as suggested. Sorry, I screwed things up a bit and wasn't able to generate an interdiff =/
Comment #6
metzlerd commentedNo problem, Thanks!
Comment #7
bkosborneComment #9
bkosborneUgh, I never actually committed this!