Append field number to accessors if there is conflict #6169
Conversation
Previously, foo_value and foo (wrapper field) will both have get/setFooValue
| @@ -16,6 +16,44 @@ | |||
|
|
|||
| class WrapperTypeSettersTest extends TestBase | |||
| { | |||
| public function testConflictNormalVsWrapper() | |||
There was a problem hiding this comment.
It looks like both functions have been renamed with a number on the end. Is that necessary? Why not just rename one of them, and keep the other unchanged?
There was a problem hiding this comment.
I think that is necessary. One field may be added before the other, and we don't want to accidentally change which field user is calling.
Consider the case if int32 normal_vs_wrapper_value = 1; is added first, and user is calling getNormalVsWrapperValue(), then someone added google.protobuf.Int32Value normal_vs_wrapper = 2;. If we rename the field 1 but not field 2, that user is suddenly reading from field 2, which is a behavior change. Similar problem exist for the other ordering too. Not to mention that it is also not clear which field getNormalVsWrapperValue() is referring to.
|
|
||
| message TestWrapperAccessorConflicts { | ||
| int32 normal_vs_wrapper_value = 1; | ||
| google.protobuf.Int32Value normal_vs_wrapper = 2; |
There was a problem hiding this comment.
Appending the field number works for this example, but what if there was also a field named normal_vs_wrapper_value_2? I'm not suggesting that that is very likely, but WDYT about a more general solution to this problem that would guarantee no conflicts. For example, inside a class, create a container of names used for methods, and each time you generate a method, add it to the container, check for conflicts, and if there is a conflict, resolve it by appending an incrementing counter - keep incrementing until the name is unique. This would also cover any other possible cases of collision (I'm not sure if any other cases exist in PHP).
There was a problem hiding this comment.
This will forces us to delay generating all accessors until we have traversed all fields of the same message. I feel this will be quite complicate.
For now, we used the same approach in java (which also has the problem of conflict after renaming)
In future, we would like to introducing some rules for naming a field, like no field can be named as a prefix of another field.
|
@fiboknacky please take a look |
| @@ -16,6 +16,44 @@ | |||
|
|
|||
| class WrapperTypeSettersTest extends TestBase | |||
| { | |||
| public function testConflictNormalVsWrapper() | |||
There was a problem hiding this comment.
I think that is necessary. One field may be added before the other, and we don't want to accidentally change which field user is calling.
Consider the case if int32 normal_vs_wrapper_value = 1; is added first, and user is calling getNormalVsWrapperValue(), then someone added google.protobuf.Int32Value normal_vs_wrapper = 2;. If we rename the field 1 but not field 2, that user is suddenly reading from field 2, which is a behavior change. Similar problem exist for the other ordering too. Not to mention that it is also not clear which field getNormalVsWrapperValue() is referring to.
Previously, foo_value and foo (wrapper field) will both have get/setFooValue