ref on hidden this param

TwoOfCups TwoOfCups at notreal.com
Mon Oct 6 06:49:57 UTC 2025


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.


More information about the Digitalmars-d mailing list