Proposal: Use term "property" instead of "field"
matthewadams opened this issue · comments
AFAIK, neither JavaScript nor TypeScript use the term "field"; it's "property". Further, in conventional OOP, the term "member" refers to both fields and methods (which is reinforced even more so in JavaScript, since all objects have keys that can contain data or functions, which are effectively "methods").
I propose to effectively rename, with appropriate backward-compatible deprecations,
MemberSelectortoPropertySelector,fieldNamePatterntopropertyNamePattern,fieldstoproperties, and- any other uses of the term "field" to "property" in code & documentation.
After all, the current MemberSelector into alignment with its own current fields property, which is defined to be of type PropertyDescriptor[], which contributes to confusion. Further, the pointcuts beforeGetter, beforeSetter, afterGetter, afterSetter, aroundGetter & aroundSetter, which intercept calls to get xxx () { /* ... */ } & set xxx (value) { /* ... */ } methods. Unless I'm mistaken, you cannot intercept property reads & writes without defining your own property methods with the get & set keywords, respectively. The documentation incorrectly describes this as "field" interception, which is a misnomer.
IMHO, if "field interception" could be supported, then that should be manifested in such a way as to not require the class whose "fields" are being intercepted to not have to define get or set property methods. I don't know if that's even possible right now.
Discussion welcome on this topic.
Sure, we can go with property. Once we resolve this issue and #70, we can publish a new major release.
We can also incorporate the rename of the Wove decorator.
We should better release the incompatible API changes (i.e. this and #67) as 1.0.0.
@mgechev Yes, since these are breaking changes, they would necessitate a 1.0.0 version.