You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's currently a test to handle instances where duplicate composite types are understood correctly... testUnderstandingOfBasicRefs
Whenever we find a cycle or a duplicated object, we'll ideally have a set of ID's and REF's. An "ID" identifies an isntance of a composite with all of the other interpretations inside. A "REF" is a reference to an object with an "ID"
There's a lot of gnarly and tricky ways where I could have cycles in some instances of these classes. An instance of A could have an instance of B that has an instance of C that refers to both the instance of B and the instance of A... for example. (You could implement that case, actually! That'd be a good start.)
Another thing (to borrow the notation I used in #74):
We don't necessarily make ordering guarantees about wether or not we see the ID of a composite first, or second... etc...
So you could write a few different tests that shift the ID/s and Refs around...
So, for example, this is one good test case for a non-graph reference:
There's currently a test to handle instances where duplicate composite types are understood correctly... testUnderstandingOfBasicRefs
Whenever we find a cycle or a duplicated object, we'll ideally have a set of ID's and REF's. An "ID" identifies an isntance of a composite with all of the other interpretations inside. A "REF" is a reference to an object with an "ID"
Suppose I have these three classes:
There's a lot of gnarly and tricky ways where I could have cycles in some instances of these classes. An instance of A could have an instance of B that has an instance of C that refers to both the instance of B and the instance of A... for example. (You could implement that case, actually! That'd be a good start.)
Another thing (to borrow the notation I used in #74):
We don't necessarily make ordering guarantees about wether or not we see the ID of a composite first, or second... etc...
So you could write a few different tests that shift the ID/s and Refs around...
So, for example, this is one good test case for a non-graph reference:
I expect the same value at the end of the understanding process if the interpretations look like this:
And this test case is a bit less helpful, but at least illustrates that there's many different ways to skin a cat:
So basically: Write some cycle tests!
Send me the link, etc whenever you make the commit and I'll review.
The text was updated successfully, but these errors were encountered: