Thrift generation variables unexpectedly change

user_11226696 0
Viewed 119

For background, I'm generating to C++, using thrift version 0.9.3, on RHEL7. Recently added a new function to an existing thrift file. When generating the cpp files from thrift and diffing the newly generated ones to the existing older ones, I noticed that the newer ones had changed parts of the code, that to me, didn't make sense to change (ie no new implementation, just variables name changes to existing code). Thought process was it probably had to do with the new function. So to convince myself it was just because of the new function, I generated the files again, without the function (essentially using the previous version of thrift file). Again, the changes remained the same.

To clarify, theres a piece of code like this in the existing cpp files:

 uint32_t _size79;
 ::apache::thrift::protocol::TType _etype82;
  xfer += iprot->readListBegin(_etype82, _size79);
 (*(this->success)).resize(_size79);

and the newer results (with or without the new function) would change the variables to this:

 uint32_t _size86;
 ::apache::thrift::protocol::TType _etype89;
 xfer += iprot->readListBegin(_etype89, _size86);
 (*(this->success)).resize(_size86);

Now I know you shouldn't try to nit pick through what thrift generates, but what might cause this to happen? I've gone through the white paper, and a few other places to try and figure out why random changes like this would happen, but couldn't figure out much. I want to be able to say, "this is okay, this is expected sometimes because of this certain process...". Part of me feels like these variables should have stayed consistent given that they came from the same thrift file, same thrift compiler version, though generated a few months apart.

Thanks. Hopefully I'm just missing a concept.

thrift
1 Answers
uint32_t _size79;

The internal variables in generated code are created by an algorithm that accepts a prefix and adds number to it. The number gets incremented each time. That's the technical explanation.

However, you should not care about it.

Note that the following applies to any kind of function or API you going to call or use in the rest of your life as a software developer.

The way how purely internal variables are used is of no significance to any piece of code outside of that routine. Although this is not about encapsulation in the OOP sense, it is somewhat comparable to that. Whatever the calling code of a particular function (or code called by it) needs to know is in the method signature and any associated documentation.

I've gone through the white paper, and a few other places to try and figure out why random changes like this would happen, but couldn't figure out much.

In other words, it is undocumented behaviour. The reason why internal implementation details are usually not documented is to prevent anybody from relying on it, and potentially building upon it. The whole idea about encapsulation is to intentionally hide such details. This allows to change the implementation at any time without affecting or breaking any code outside of it.

This is also the reason why relying on undocumented stuff is a doubly edged sword: It allows for greater flexibility, but that power comes at the cost of risking compatibility with future versions, even minorish hotfix updates.

Part of me feels like these variables should have stayed consistent given that they came from the same thrift file, same thrift compiler version, though generated a few months apart.

The reason for that feeling is the assumption that you have to know (and care about) what happens inside. This assumption is incorrect. Just pretend for a moment that this method is a black box: You would not even notice the variable names had changed. Would that change a thing at all to the code calling or using it?

user_4994660
Related