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
The MediatedConnection handler has a public from_parts API, which allows consumers to reconstruct their MediatedConnection objects with typed data.
This is useful to consumers who have data representing a 'mediatedconnection' in another form (e.g. they are coming from another lib, or they are internally storing 'connections' in their own format).
from_parts allows consumers to not depend on the exact format/result of serializing/deserializing the handler (which may change over time, especially with the recently proposed typestate patterns).
However other handlers - Connection, Prover, Verifier, Holder, Issuer don't have such a function, and the only way to reconstruct them is by serializing and deserializing. So if you want to reconstruct them, and you don't have a serializing version of the handler, your only option is to hackily recreate the serializing format with your own data and try deserialising it...
So i'd propose that, like MediatedConnection, handlers should have an alternative (re-)constructor method such as from_parts. In making this method, we'd need to ensure that consumers can publicly access ways to construct the 'parts' they need.
E.g. for Connection::from_parts(..., state: SmConnectionState), we'd need to ensure that consumers can construct the SmConnectionState object virtually from scratch - which I believe is already the case, but just pointing it out.
Alternatively, we could make the fields of handlers all public, but IMO from_parts constructors would be cleaner.
The text was updated successfully, but these errors were encountered:
Let me know if you agree or disagree with this proposal - was there a reason that all other handlers are missing the from_parts constructor? I will start working on an PR for Connection handler in the meantime
Update; from the meeting last week, we agreed to include from_parts and to_parts operators in handlers. These were added to Connection with the typestate MR #740 . However other handlers are still missing them
The
MediatedConnection
handler has a publicfrom_parts
API, which allows consumers to reconstruct theirMediatedConnection
objects with typed data.This is useful to consumers who have data representing a 'mediatedconnection' in another form (e.g. they are coming from another lib, or they are internally storing 'connections' in their own format).
from_parts
allows consumers to not depend on the exact format/result of serializing/deserializing the handler (which may change over time, especially with the recently proposed typestate patterns).However other handlers - Connection, Prover, Verifier, Holder, Issuer don't have such a function, and the only way to reconstruct them is by serializing and deserializing. So if you want to reconstruct them, and you don't have a serializing version of the handler, your only option is to hackily recreate the serializing format with your own data and try deserialising it...
So i'd propose that, like
MediatedConnection
, handlers should have an alternative (re-)constructor method such asfrom_parts
. In making this method, we'd need to ensure that consumers can publicly access ways to construct the 'parts' they need.E.g. for
Connection::from_parts(..., state: SmConnectionState)
, we'd need to ensure that consumers can construct theSmConnectionState
object virtually from scratch - which I believe is already the case, but just pointing it out.Alternatively, we could make the fields of handlers all public, but IMO
from_parts
constructors would be cleaner.The text was updated successfully, but these errors were encountered: