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

Remove Field._CHECK_ATTRIBUTE #2720

Closed
wants to merge 1 commit into from
Closed

Remove Field._CHECK_ATTRIBUTE #2720

wants to merge 1 commit into from

Conversation

lafrech
Copy link
Member

@lafrech lafrech commented Jan 4, 2025

This is a first step towards #1046/#2039 (those issues could probably be merged).

It introduces an asymmetry because there is no accessor concept when deserializing.

Ultimately, I'd like to remove those fields. As I suggest in #2039, the accessor method could be passed to any field, so as to combine the capability to customize the accessor (like in Function/Method) and the field feature related to its type (String, Integer, etc.).

I don't mind postponing this to 5.0 if we're not confident this is the right direction to take and we want to have the full rework complete.

Copy link
Member

@sloria sloria left a comment

Choose a reason for hiding this comment

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

seems like a good incremental step to me. i wouldn't even consider this backwards-incompatible since _CHECK_ATTRIBUTE was private

@sloria sloria added this to the 4.0 milestone Jan 4, 2025
@sloria
Copy link
Member

sloria commented Jan 5, 2025

@lafrech feel free to merge if there's no other changes you plan to make

@lafrech
Copy link
Member Author

lafrech commented Jan 5, 2025

I think #2039 (comment) might be the way to go.

Not sure I'll carve the time to work on it in the next days, although if my intuition is correct, it might be a nice and complete solution and it may not require so much work.

Depends on how eager we are to release. No need to rush IMHO.

@sloria
Copy link
Member

sloria commented Jan 5, 2025

#2039 (comment) sounds like a good plan. no rush on releasing, but i would like to prevent 4.0 from having too many large breaking changes (this is not to discourage implementation of #2039--it's mostly my fault for the 4.0 scope creep 🙃 ).

@lafrech
Copy link
Member Author

lafrech commented Jan 6, 2025

Let's hold this this until #2039. I doesn't bring much by itself and might catch people in the wild with fancy setups, like Method field in List field or whatever.

If we go on with #2039, serialize signature changes so all custom fields are broken and most libs must be updated and all. No problem if we postpone it to make the transition more incremental.

@sloria
Copy link
Member

sloria commented Jan 6, 2025

sounds good. i think postponing #2039 is a good idea

@sloria
Copy link
Member

sloria commented Jan 6, 2025

@lafrech should we close this PR for now?

@lafrech lafrech modified the milestones: 4.0, 5.0 Jan 6, 2025
@lafrech
Copy link
Member Author

lafrech commented Jan 6, 2025

Or make it a draft but I don't think we can do that.

I just moved it to 5.0. Keeping it to keep that commit somewhere. We may close it, no big deal.

@sloria sloria deleted the branch 4.0 January 6, 2025 17:25
@sloria sloria closed this Jan 6, 2025
@sloria
Copy link
Member

sloria commented Jan 6, 2025

woops, this auto-closed when i merged 4.0 into dev and deleted 4.0. We can reopen this when the time comes

@lafrech
Copy link
Member Author

lafrech commented Jan 6, 2025 via email

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

Successfully merging this pull request may close these issues.

2 participants