On Sunday, 5 October 2025 at 07:40:25 UTC, TwoOfCups wrote:
> On Sunday, 5 October 2025 at 06:56:27 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>
>> Why not use a static method instead?
>
>
> yeah i was thinking about doing that but like i said the serialization code is already a fucking mess of weird little special cases. so now i have to add checks for if the proxy functions are static and handle in a different way.

I use a static method for (de)serialization, it works pretty well.

You should require static methods IMO, this is the right abstraction. Because you are creating a new instance, and that requires different semantics than just overwriting an existing one.

-Steve

On Sunday, 5 October 2025 at 21:34:01 UTC, Steven Schveighoffer wrote:
> On Sunday, 5 October 2025 at 07:40:25 UTC, TwoOfCups wrote:
>> On Sunday, 5 October 2025 at 06:56:27 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>>
>>> Why not use a static method instead?
>>
>>
>> yeah i was thinking about doing that but like i said the serialization code is already a fucking mess of weird little special cases. so now i have to add checks for if the proxy functions are static and handle in a different way.
>
> I use a static method for (de)serialization, it works pretty well.
>
> You should require static methods IMO, this is the right abstraction. Because you are creating a new instance, and that requires different semantics than just overwriting an existing one.
>
> -Steve

My original design was to just disallow classes completely. It was fully oriented towards basic types, sum types, structs and ranges. And it is pretty nice as just that. I just didn't want to do a type registry to make class inheritance in deserialization possible.

But time passes and the desire for inheritance in my serialization became too tempting. So I added a class registry and now I'm trying to go the next step of being able to properly serialize arbitrary graphs of object references where the correct references could be restored on deserialization..

so some kind of uuid gets written when an aggregate has an object of a special type of class. For general objects I just make a new object and serialize/deserialize the data in place.

But for a special type of object (the base class for all entities in a game) I want this uuid lookup system.

it is made more messy because I want the serialization code to handle top level serialization calls to these objects directly, aka serialize the data no uuid stuff, but then if this type is seen to be a member then we do the uuid behavior.

so my system has been evolving from one design decision to the next. I am trying to work with what I already have without needing to redesign large parts.