Skip to content

Conversation

@gulugulubing
Copy link
Contributor

Now we have 3 official policy:

  1. caseInsensitive
  2. defaultValue
  3. DateString

@schveiguy
Copy link
Owner

Let's focus on one thing at a time.

DefaultValuePolicy doesn't seem descriptive enough (it only focuses on floating point), plus I don't see the use case. You can establish default values for fields via:

struct S
{
    float x = 0;
}

This could be an example policy to document in a unittest.

DTStringPolicy is not meant to be a usable policy by user code. It is a demonstration on how you can define a policy. It should stay as a documented unittest (it should be documented if not already). There are lots of ways to represent dates and times as strings. There are lots of date/time types in phobos. This isn't nearly as complete a policy as I would like for handling dates and times. I don't think you should focus on making this a defined policy.


When I said "So I think yes, we can probably do some more common things in the "official" implementation, as options." I meant to add options to the default serialization policy (comparable to the ReleasePolicy enum).

I don't think lots of individual official policies makes sense. You can't compose policies together (or at least we haven't thought about how this should work). If we want to provide official options, I think it should be through the default policy.

The case insensitive policy looks to be a useful addition to the DefaultDeserializationPolicy. But since it drastically changes how things are deserialized, it should be a compile-time parameter, not a runtime one. And since the real work is done via the default onField function, the compile-time parameter should go there. This allows custom policies to access it.

@gulugulubing
Copy link
Contributor Author

Go it, I have moved DefaultValuePolicy and DTstring to unittest and added caseInsentive as template parameter to the DefaultDeserializePolicy and onField function.
I tried to intergrate the caseInsentive into the switch branch in onField, but it looks impossible.

Copy link
Owner

@schveiguy schveiguy left a comment

Choose a reason for hiding this comment

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

I approve the general design. Just think about how you want to refactor the string switch stuff.

@schveiguy schveiguy merged commit 4d2eb7f into schveiguy:master Aug 15, 2025
6 checks passed
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.

2 participants