Generate Classic Payments after mustache templates update

[gcatanese]

PR to generate the Classic Payments models.

All models have been updated to handle the nullable value (Mustache templates have been updated as part of #1603).

There are no changes (no new attributes, etc..).

[gemini-code-assist]

Summary of Changes

Hello @gcatanese, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the serialization behavior of Classic Payments models. The primary goal is to ensure that when a field is explicitly set to null, it is correctly represented as null in the outgoing JSON payload, rather than being entirely absent. This change is a direct consequence of an update to the underlying Mustache templates, enhancing API consistency and data integrity for nullable fields.

Highlights

• Nullable Value Handling: Updated all Classic Payments models to correctly handle nullable values, ensuring that fields explicitly set to null are included in the JSON payload rather than being omitted.
• Serialization Logic: Introduced isSet<PropertyName> boolean flags for each model property, along with a new getExplicitNulls() method, to control the explicit serialization of null values based on whether an attribute was intentionally set.
• No Functional Changes: Confirmed that these updates do not introduce any new attributes or alter existing business logic, focusing solely on serialization behavior as a result of a Mustache templates update.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to conditionally serialize null values for model properties, which is a useful feature for handling nullable fields in API requests. The implementation uses isSet... flags for each property and a general includeNullValues flag to control the behavior, which seems correct.

However, I've noticed a potential limitation in the design. Once a property is set (even to null), its corresponding isSet... flag is set to true and there is no way to reset it to false. This means a property cannot be "unset" to be omitted from serialization again, short of creating a new object instance. This could be inconvenient for developers who might want to build a request object and then dynamically remove some properties before sending it.

I've added a specific comment with a suggestion to add unset...() methods for each property to provide more flexibility. This would improve the usability of the generated model classes.