Convert needlessly public methods and properties to internal. #3
Conversation
|
The tests fail since it is testing the support package as a separate package.
Is this something that has come up, or just an abstract problem? If we want to distribute it as a swift package in the future, then we will need to revert these changes. |
dbart01
force-pushed
the
buy-sdk
branch
2 times, most recently
from
2f0141e to
91da590
Compare
| // Generated from <%= script_name %> | ||
| // | ||
| // <%= type.name %>.swift | ||
| // Buy |
There was a problem hiding this comment.
Why are these instances of "Buy" sitting around?
| // AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
| // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, | ||
| // OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN | ||
| // THE SOFTWARE. |
There was a problem hiding this comment.
Is the inline license necessary? Why not just license the whole repo?
There was a problem hiding this comment.
This is a license for the generated code, which will end up being in another repo. I'm not sure if the license in the generated code is necessary though.
- add InputValue type and extensions - modify generation to use InputValue enums in serialize() - declare all optional values in Input objects at InputValue<T>
|
The purpose was originally to sync changes that we needed to make on Buy SDK. This was back in March. As for the recent commit with explicit null support, @sav007 and I had a long discussion about the kind of API we want to expose in Mobile Buy SDK and this is the outcome. You're more than welcome to adopt it as well. |
3 participants
The GraphQL support file is generally included in the module that also contains the generated files. There's no need to declare many
internalmethods and properties aspublic. Doing so increases the risk of end-users incorrectly using the API and pollutes the auto-complete namespace.