Fix json marshalling #8
Conversation
This reverts commit 21fb15e, because: - There was no motivation for this upgrade (nothing specified in the commit message). - It might introduce bugs that we don't want to deal with, at the moment. - We might revert this revert shortly after finishing our milestone4 (closing channels).
canndrew
force-pushed
the
nblockchain-master-with-json-marshalling
branch
2 times, most recently
from
78dc243
to
6234c40
Compare
| @@ -333,23 +335,24 @@ module Primitives = | |||
| static member (*) (a: FeeRatePerKw, b: uint32) = | |||
| (a.Value * b) |> FeeRatePerKw | |||
| /// Block Hash | |||
| type BlockId = | BlockId of uint256 with | |||
| member x.Value = let (BlockId v) = x in v | |||
| [<Struct>] | |||
There was a problem hiding this comment.
how about adding [<StructuralComparison;StructuralEquality>] instead of [<Struct>] ?
There was a problem hiding this comment.
Is there an advantage to that? My understanding is that [<Struct>] makes the type a thin wrapper around uint256, which seems to be what we want.
There was a problem hiding this comment.
@canndrew Define thin wrapper? There are many differences between classes and structs (e.g. allocated on stack instead of heap, AFAIR). But if what we care about here is only comparison, then I'd like to know if using [<StructuralComparison;StructuralEquality>] works, because if it does:
a) why not do this instead? the change would be more readable because it would declare intent by itself;
b) some cases I see which are now [<Struct;CustomComparison;CustomEquality>] may not need to change at all.
There was a problem hiding this comment.
To me "thin wrapper" means, at least in this case, that the outer layer of the value is allocated on the stack (so there aren't two pointer-indirections) and that the type forwards equality to the wrapped type.
I agree that [<StructuralComparison;...>] arguably expresses the intent more directly, however I had to add [<Struct;...>] to some of those types to get it to compile in the first place. I only added it to 3 more types when fixing the tests.
There was a problem hiding this comment.
Specifically, (since I just tried to build without Struct to see what the errors are), I get the error: Only record, union, exception and struct types may be augmented with the 'ReferenceEquality', 'StructuralEquality' and 'StructuralComparison' attributes.
This is the error I get if I, for instance, replace the [<Struct;StructuralComparison;StructuralEquality>] on TxId with just [<StructuralComparison;StructuralEquality>].
There was a problem hiding this comment.
interesting... but in the case of this hunk:
- [<CustomEquality;CustomComparison;StructuredFormatDisplay("{AsString}")>]
+ [<Struct;CustomEquality;CustomComparison;StructuredFormatDisplay("{AsString}")>]
why is Struct needed? if the equality and comparison are still custom! do tests pass if you remove this hunk from the PR?
There was a problem hiding this comment.
The error in this case is: This type uses an invalid mix of the attributes 'NoEquality', 'ReferenceEquality', 'StructuralEquality', 'NoComparison' and 'StructuralComparison'
There was a problem hiding this comment.
I don't understand, if that was the case master branch wouldn't compile at all, because it currently has [<CustomEquality;CustomComparison;StructuredFormatDisplay("{AsString}")>] before the changes from your PR.
This is a fix for changes introduced in joemphilips#118 which caused chain hashes to get serialized in reverse order.
|
@canndrew please rebase this PR (and rename title from "Implement" to "Fix"). |
A lot of types in DotNetLightning are defined as discriminated unions
with a single constructor with the same name as the type. eg:
type NodeId = | NodeId PubKey
This commit redefines these types as:
type NodeId(id: PubKey) = ...
The main motivation for this is that having types and constructors with
the same name breaks the json serialization library on older mono
versions. It can also lead to confusing error messages. Besides that,
it's also somewhat pointless to define a type as a discriminated union
but then only give it one variant.
This commit adds the JsonMarshalling module which defines json serialization converters for a bunch of types exported by DotNetLightning. This allows the consumer of DotNetLightning to serialize the channel state to a wallet file.
canndrew
force-pushed
the
nblockchain-master-with-json-marshalling
branch
from
537f6e3
to
afd7f3a
Compare
knocte
force-pushed
the
master
branch
6 times, most recently
from
135c9bb
to
02564ea
Compare
knocte
force-pushed
the
master
branch
3 times, most recently
from
dd99cda
to
08262fb
Compare
knocte
force-pushed
the
master
branch
8 times, most recently
from
48f2a9f
to
06581b9
Compare
knocte
force-pushed
the
master
branch
3 times, most recently
from
f9839d5
to
6281acc
Compare
knocte
force-pushed
the
master
branch
3 times, most recently
from
9f9f73e
to
2883c78
Compare
canndrew
force-pushed
the
master
branch
4 times, most recently
from
f817da9
to
0340b0b
Compare
knocte
force-pushed
the
master
branch
3 times, most recently
from
0389f6a
to
60d2401
Compare
knocte
force-pushed
the
master
branch
4 times, most recently
from
419cd8d
to
f0461b4
Compare
knocte
force-pushed
the
master
branch
4 times, most recently
from
37fe5af
to
1f418fe
Compare
knocte
force-pushed
the
master
branch
5 times, most recently
from
bd34034
to
b67e13f
Compare
This PR implements json marshalling in DNL where it belongs. This allows geewalet tests to pass on stockmono.
It also redefines single-variant discriminated union types as regular non-discriminated-union types.