Yes, and also dual interpretations it didn't handle (two pointers to the same thing that claimed to be different types). Both of these would be pretty easy to handle if you were trying to make a system that was meant to be a "standard" system people could use as a library.
-
-
Replying to @cmuratori @Jonathan_Blow and
IIRC the first problem hurts execution time a fair bit because you're not just doing pointer equality comparisons, you're doing range comparisons. And speed was (is!) important. I guess we could have had two different serialisation paths.
1 reply 0 retweets 1 like -
Replying to @tom_forsyth @Jonathan_Blow and
But it also requires two traversals, which is even worse. So not supporting, or optionally supporting it, probably does make sense since it is almost never done.
1 reply 0 retweets 2 likes -
Replying to @cmuratori @Jonathan_Blow and
In ten years of using it in apps, I've only ever vaguely wanted this support twice. Once I worked around it with a pointer-to-start+plus index (it was an array), rather than direct pointer. The other time was actually a terrible idea once I thought harder about the problem.
1 reply 0 retweets 2 likes -
Replying to @tom_forsyth @Jonathan_Blow and
Yeah, I don't consider an actual problem with Granny's system, it's just interesting to think about how much speed you sacrifice if you want to support it...
1 reply 0 retweets 2 likes -
Replying to @cmuratori @Jonathan_Blow and
You could also annotate the pointers as whether or not they are this special type or not, so only do the expensive test for them. But it's still two passes for the whole thing even if there's only one pointer like that.
1 reply 0 retweets 1 like -
Replying to @tom_forsyth @cmuratori and
Oh - you could do a pre-pass of the TYPE system and "poison" that whole branch of TYPES. Then you make sure that branch gets done last. There will be cases (e.g. circular references) that can't be solved like this though. Then you still need two passes.
1 reply 0 retweets 1 like -
Replying to @tom_forsyth @cmuratori and
Never seen serialization work well when references were to isolated objects: a good reference refers to an array, and to an index in that array. e.g. "texture library FOO, entry #12" This at least keeps the door open to batch processing, which you eventually need anyway.
2 replies 0 retweets 8 likes -
Replying to @bmcnett @tom_forsyth and
Everything about how a language like C# is designed and their paradigms teaches people not to do stuff like that though, because C# is just like "we can just solve this with reflection", and then you get overwrought stuff like BinaryFormatter and gaping security holes
3 replies 0 retweets 1 like -
And I haven't given that problem any thought, but my first reaction is that if you allow people to write arbitrary initialization functions for objects, I don't see any way to really guarantee proper serialization. I mean how can the serialization system analyze that?
1 reply 0 retweets 0 likes
So it seems like a mildly terrifying paradigm to embrace because you move from an easily-solvable problem (C struct graph serialization) to a potentially impossible problem (interdependent function order serialization?) and that sounds like the ultimate sadness.
-
-
Replying to @cmuratori @bmcnett and
The ultimate sadness is pretty much it. I don't know how other C# devs deal with it, personally I just have a serialize/deserialize method pair now that renders to/from primitive value types. Tends to be a lot more doable, robust, secure, and performant
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.