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

3.0 serialization source generator #1868

Draft
wants to merge 3 commits into
base: 5.0
Choose a base branch
from

Conversation

FiniteReality
Copy link
Member

Working in a separate branch so that more testing and discussion can be done without screwing up history. (I.e. all of the changes can be squashed when merging.)

This is the fabled 3.0 serialization source generator. It's by no means finished, and it's by no means the prettiest code either. Some decent code review and cleanup suggestions would be nice - this is just the minimum viable product in order to prove we're able to even do this.

@FiniteReality
Copy link
Member Author

FiniteReality commented Jun 5, 2021

Design discussion from dev server:

  • Current records don't have properties documented
  • Primary ctor was primarily for convenience w/ naming and ordering, since parameter name = property name
  • If we're specifying properties manually, we don't need a ctor at all and can just use init accessors

So, that means we'll do something like this:

public enum ChannelType
{
    GuildText
}

public record Channel
{
    public ChannelType Type { get; init; }
    public ulong Id { get; init; }
}

public record GuildTextChannel : Channel
{
    public GuildTextChannel()
    {
        Type = ChannelType.GuildText;
    }
}

@SubZero0
Copy link
Member

SubZero0 commented Jun 6, 2021

As discussed in DM, we should have a way to not be tied to the same naming as discord.
It could be solved with:

  • Override attribute: overrides the automatic snake case conversion
  • Json name attribute: will be used instead of the snake case conversion

I feel the json name attribute would be the best option for a few reasons:

  1. If we are going to check every attribute for the override one, we could just go for a sure one that will already have the correct naming.
  2. We can use it as a way to describe if the parameter should be ignored or not.
  3. Easier to use instead of having to know how the library will convert the property name internally to match it (for future contributions).

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.

None yet

2 participants