New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Accessors #12310
Remove Accessors #12310
Conversation
|
644c910
to
b9ca4f8
Compare
b340a28
to
5ba7a01
Compare
ae8ad50
to
300f922
Compare
42f1403
to
64139fc
Compare
There's still some We may also want to deprecate these methods:
I see you deprecated some of them in our docs, but we can also add the |
… method in example
e6a39cd
to
b63364c
Compare
I think these fall into the category of being existing documented methods. We may want to consider exposing as properties and deprecating long-term?
As noted in comments w/ Josh, this method should stay. I just missed documenting that Android has had it around since forever. I'll push that change to the docs. We didn't expose this as a property before, so I am deprecating it for now but not removing it.
Given the nature of the API it felt odd to me to try and make it property only for text (but you'd need to use get/set for "data"). This method has been around forever and is documented. We could consider deprecating and pushing towards a property access usage. But we haven't documented it as a property ever - and I'm trying to only remove "auto-generated" getter/setters for documented properties but retain existing documented methods when possible. So I think it may make sense to expose as a property here and eventually deprecate the method to prefer the property.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iOS looks good.
JIRA: https://jira.appcelerator.org/browse/TIMOB-26119
Description:
This PR removes the getter/setter methods for properties where we can directly get/set the value for that property. If a get/set method is explicitly defined, it should not be removed. We've been threatening to remove these for years now. Time to rip off the band-aid.
Note that a lot of work is in the test suite. I needed to clean them up and explicitly test that many properties don't have accessors anymore to help me find what needed to be changed.
So the basic guideline I tried to follow here was:
@Kroll.method
and@Kroll.getProperty
(or@Kroll.setProperty
) I'd remove the@Kroll.method
.Ti.Network.HTTPClient.setRequestHeader('headerName', 'value');
QuickSettingsService
it had getter/setter pairs for underlying properties but did not expose the properties. In that case, I exposed the properties, documented them and left the getter/setters but marked them as deprecated in api docs.