Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Make SerialDescriptorForNullable.original public #2633

Merged

Conversation

Chuckame
Copy link
Contributor

Closes #2631

@Chuckame Chuckame force-pushed the feat/accessible-original-descriptor branch from 2532763 to e555fdf Compare April 15, 2024 23:27
Copy link
Member

@sandwwraith sandwwraith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should also do a couple more things:

  1. Update public API dump (see https://github.com/Kotlin/kotlinx.serialization/blob/master/CONTRIBUTING.md#updating-the-public-api-dump)
  2. Add some tests for the change — that x.nullable.unwrapNullable === x, that for @Serializable class X(val s: String?), val n = X.serializer().descriptor.getElementDescriptor(0) results in n.isNullable == true and n.unwrapNullable == String.serializer().descriptor, for your use case, etc.

@Chuckame Chuckame force-pushed the feat/accessible-original-descriptor branch from 39e8694 to 5d22d74 Compare April 17, 2024 14:01
@Chuckame
Copy link
Contributor Author

Chuckame commented Apr 17, 2024

Following the contributing guide, I've rebased onto dev (but the PR is on master, I cannot change it ⚠️), tests have been added, and doc+knit+apiDump executed @sandwwraith ! 🚀

@sandwwraith sandwwraith changed the base branch from master to dev April 17, 2024 14:21
* @see KSerializer.nullable
*/
@ExperimentalSerializationApi
public val SerialDescriptor.unwrapNullable: SerialDescriptor
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking at the api dump, I've realized that unwrap is actually a verb, and its counter-intuitive to have a verb in property name (https://kotlinlang.org/docs/coding-conventions.html#choose-good-names). So it should be either

  1. A function SerialDescriptor.unwrapNullable()
    or
  2. A property with a noun, e.g. unwrappedNullable.

I'm not sure what is better. Doing (1) will bring asymmetry with .nullable. (2) is confusing, because it is not clear what 'unwrapped' is since we do not have 'wrapped' anywhere else. Besides, 'unwrappedNullable' sounds like some flavor of a nullable thing, but in reality, returned descriptor may be non-nullable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I'm feeling the same. I would prefer unwrappedNullable to not have this asymmetry. I'll commit now. If you feel not comfortable, could we have a third person reviewing this to help chosing a better name ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shanshin or @qwwdfsad may help here, I guess

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, we can do unwrappedOriginal and also unwrap WrappedSerialDescriptor.original (I've looked at all the SerialDescriptors and only SerialDescriptorForNullable and WrappedSerialDescriptor would have sense of unwrapping the original descriptor)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Chuckame It seems to be that the route of introducing a WrappedSerialDescriptor interface would make a lot of sense, it would also future proof the design to support other wrapping descriptors (and not special case the nullable descriptor only)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea, but it would mean also renaming the current data class WrappedSerialDescriptor to something else to allow creation of the interface. What do you think @sandwwraith ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the route of introducing a WrappedSerialDescriptor interface would make a lot of sense, it would also future proof the design to support other wrapping descriptors

IMO this is way out of scope of this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT of nonNullableOriginal name? We can add to the documentation that this property "does not affect descriptors that were created as nullable by directly implementing SerialDescriptor interface."

Copy link
Contributor Author

@Chuckame Chuckame Apr 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New doc, is it okay for you @sandwwraith ? I also renamed to nonNullOriginal (pushed)


 * Returns non-nullable serial descriptor for the type, only if this descriptor has been auto-generated (plugin
 * generated descriptors) or with `.nullable` extension on a descriptor or serializer.
 *
 * Otherwise, returns this.
 * 
 * It may return nullable descriptor if this descriptor has been created manually as nullable by directly implementing SerialDescriptor interface.
 *

@Chuckame Chuckame force-pushed the feat/accessible-original-descriptor branch from 7a82e70 to 5d96ac7 Compare April 17, 2024 16:15
@sandwwraith sandwwraith self-assigned this Apr 17, 2024
Copy link
Member

@sandwwraith sandwwraith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, looks good to me

@sandwwraith
Copy link
Member

@Chuckame You need to update apiDump with tool: getNonNullOriginal alphabetically goes before getNullable

@sandwwraith sandwwraith self-requested a review April 18, 2024 15:54
@Chuckame Chuckame force-pushed the feat/accessible-original-descriptor branch from 588a5ae to 56b5c50 Compare April 18, 2024 15:59
@Chuckame
Copy link
Contributor Author

@sandwwraith it's ready, apiDump done, doc updated. When do you think it could be released ?

@sandwwraith
Copy link
Member

@Chuckame We usually do releases around Kotlin's release. Given that 2.0.0 is just around the corner, I think it will be in about a month.

@Chuckame
Copy link
Contributor Author

Ok thanks, so I'll wait this PR release before releasing on my side.

@sandwwraith sandwwraith merged commit c7bcaf1 into Kotlin:dev Apr 18, 2024
3 checks passed
@sandwwraith
Copy link
Member

Thank you!

@Chuckame
Copy link
Contributor Author

Can I access to a snapshot build until the release ?

@Chuckame Chuckame deleted the feat/accessible-original-descriptor branch April 18, 2024 20:21
@sandwwraith
Copy link
Member

Unfortunately, we don't do snapshot builds. You can build it yourself and publish it to your maven local (https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/building.md) if you want to test the changes with your library

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make accessible the original descriptor when wrapped into nullable
3 participants