Loop in class building prevent compiler termination

[trethaller]

When a serializable class ends-up referencing itself in its graph of references, this error can occur:
Loop in class building prevent compiler termination

The current workaround is to declare the reference of an more abstract type, eg, Serializable, and add strongly typed get/set.

Should this be standardized? For example:

@:s(sub) var subRef : MyClass;

@:storeAs(ParentClass) @:s var subRef : MyClass;

@:selfRef @:s var subRef : MyClass;

[trethaller]

Any preference ?

[ncannasse]

Ideally this should be done automatically without the user having to tag such cases.

[trethaller]

What would be the downside of systematically storing vars as Serializable and performing casts in the get/set functions?

[ncannasse]

Extra runtime type check at every access Le mer. 21 avr. 2021 à 20:20, trethaller ***@***.***> a écrit :

…

What would be the downside of systematically storing vars as Serializable and performing casts in the get/set functions? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZXQFM7VFM7BT73SQF5ADTJ4JOTANCNFSM4YU5TITA> .

[trethaller]

I'm wondering how much of a problem that is for ref fields. I see that it would be too bad for things like x,y,z, but not sure we actually have performance critical code using @:s refs?
I don't think using to the abstract type automatically when a loop is detected is a good idea: if the casting cost is a problem, then it would be very opaque for the user why some fields have it and some don't.
So unless we are okay with the type checks being there for all refs (which I'm not sure is really a problem?) I don't see a better way than to flag fields manually. The hardest part being finding a name that makes sense 😂

[ncannasse]

I would need a reproducible example so I can fix that :)