[TIMOB-26119] TiAPI: Deprecate getter/setter accessor methods for properties
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2018-08-02T15:37:58.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 8.0.0 |
Components | Android, iOS, TiAPI, Windows |
Labels | n/a |
Reporter | Christopher Williams |
Assignee | Christopher Williams |
Created | 2018-06-11T12:18:49.000+0000 |
Updated | 2021-04-14T15:56:00.000+0000 |
Description
We currently generate get/setX methods to handle reading/writing properties - in addition to the typical property access. This is atypical for Javascript, and is more common in a language like Java.
We should consider deprecating these additional methods and preferring access via typical property routes such as
object.property
or object['property']
On reason we may want to do this is to reduce common boilerplate code that is an annoyance to write/maintain when having to duplicate code for a single property.
A good example can be seen in our Windows implementation:
https://github.com/appcelerator/titanium_mobile_windows/blob/master/Source/TitaniumKit/include/Titanium/UI/View.hpp#L170
https://github.com/appcelerator/titanium_mobile_windows/blob/master/Source/TitaniumKit/include/Titanium/UI/View.hpp#L228-L229
We basically have to define the same property 3 times (and then implement it too). We get away with getting these for "free" on iOS due to our reflection based implementation, but moving to a more proper binding would result in the same sort of boilerplate there as we have on Windows.
+1 for deprecating in 8.0.0 and removing in 9.0.0. We may be able to spit out a warning message for every computed getter, at least for iOS I could think of a way. Once the log gets messy for the devs, they will migrate asap. We could even add a migration step for this, to search for the getters / setters and offer to migrate them for them. I like the general idea of a "migration framework" for Titanium, e.g. - Generel: Computed accessors -> properties - iOS: Old imports to framework import (as part of the Swift module effort), manifest changes - Android: manifest changes on V8 breaking changes (we already do that since 7.0.0).
This has been merged into the 'next' branch which is our current landing ground for 8.0.0 changes. So while this is merged, it is not on master and hasn't had any specific QE involvement yet. Once we're ready to target 8.0.0 on master this will get merged over.