Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prep for 0.11.0 release #48

Merged
merged 2 commits into from
Feb 9, 2024
Merged

Prep for 0.11.0 release #48

merged 2 commits into from
Feb 9, 2024

Conversation

jsdw
Copy link
Collaborator

@jsdw jsdw commented Feb 9, 2024

0.11.0 - 2023-02-09

Up until now, this crate depended heavily on scale_info to provide the type information that we used to drive our decoding of types. This release removes the explicit dependency on scale-info, and instead depends on scale-type-resolver, which offers a generic TypeResolver trait whose implementations are able to provide the information needed to decode types (see this PR for more details). So now, the traits and types in scale-decode have been made generic over which TypeResolver is used to help decode things. scale-info::PortableRegistry is one such implementation of TypeResolver, and so can continue to be used in a similar way to before.

The main breaking changes are:

Visitor trait

The scale_decode::Visitor trait now has an additional associated type, TypeResolver.

The simplest change to recover the previous behaviour is to just continue to use scale_info::PortableRegistry for this task, as was the case implicitly before:

struct MyVisitor;

impl Visitor for MyVisitor {
  // ...
  type TypeResolver = scale_info::PortableRegistry;

  // ...
}

A better change is to make your Visitor impls generic over what is used to resolve types unless you need a specific resolver:

struct MyVisitor<R>(PhantomData<R>);

impl <R> MyVisitor<R> {
  pub fn new() -> Self {
    Self(PhantomData)
  }
}

impl <R: TypeResolver> Visitor for MyVisitor<R> {
  // ...
  type TypeResolver = R;

  // ...
}

IntoVisitor trait

scale_decode::IntoVisitor is implemented on all types that have an associated Visitor that we can use to decode it. It used to look like this:

pub trait IntoVisitor {
    type Visitor: for<'scale, 'resolver> visitor::Visitor<
        Value<'scale, 'resolver> = Self,
        Error = Error,
    >;
    fn into_visitor() -> Self::Visitor;
}

Now it looks like this:

pub trait IntoVisitor {
    type AnyVisitor<R: TypeResolver>: for<'scale, 'resolver> visitor::Visitor<
        Value<'scale, 'resolver> = Self,
        Error = Error,
        TypeResolver = R,
    >;
    fn into_visitor<R: TypeResolver>() -> Self::AnyVisitor<R>;
}

What this means is that if you want to implement IntoVisitor for some type, then your Visitor must be able to accept any valid TypeResolver. This allows DecodeAsType to also be generic over which TypeResolver is provided.

DecodeAsType

This trait previously was specific to scale_info::PortableRegistry and looked something like this:

pub trait DecodeAsType: Sized + IntoVisitor {
    fn decode_as_type<R: TypeResolver>(
        input: &mut &[u8],
        type_id: u32,
        types: &scale_info::PortableRegistry,
    ) -> Result<Self, Error> {
        // ...
    }

Now, it is generic over which type resolver to use (and as a side effect, requires a reference to the type_id now, because it may not be Copy any more):

pub trait DecodeAsType: Sized + IntoVisitor {
    fn decode_as_type<R: TypeResolver>(
        input: &mut &[u8],
        type_id: &R::TypeId,
        types: &R,
    ) -> Result<Self, Error> {
        // ...
    }

This is automatically implemented for all types which implement IntoVisitor, as before.

Composite and Variant paths

Mostly, the changes just exist to make things generic over the TypeResolver. One consequence of this is that Composite and Variant types no longer know their path, because currently TypeResolver doesn't provide that information (since it's not necessary to the actual encoding/decoding of types). If there is demand for this, we can consider allowing TypeResolver impls to optionally provide these extra details.

@jsdw jsdw requested a review from a team as a code owner February 9, 2024 11:40
Copy link
Contributor

@tadeohepperle tadeohepperle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

CHANGELOG.md Outdated Show resolved Hide resolved
Copy link
Member

@niklasad1 niklasad1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@jsdw jsdw merged commit 0ac239a into main Feb 9, 2024
10 checks passed
@jsdw jsdw deleted the release-v0.11.0 branch February 9, 2024 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants