Representing Objects/Classes

[librasn]

Representing Objects/Classes

[benmaddison]

@XAMPPRocky I would be happy to help with this design: it's a subject that I have spent a fair amount of time thinking about recently.
Where are you on this topic? Have you started any implementation work yet?

[XAMPPRocky]

@benmaddison I don't have any thoughts currently, as I've never quite wrapped my head around them. Though I guess the best reference right now is the ObjectType in the SMI crate.

[benmaddison]

The SMI OBJECT-TYPE is a old-style MACRO rather than a CLASS, so the parallel isn't perfect.
But nevertheless, it looks like we are thinking along similar lines.

I have created an example module demonstrating the use of an object class as a table constraint on an ASN.1 type, and an accompanying rust type/trait hierarchy to go with it.
I have annotated the module to try help explain how it all fits together. You're very welcome to ask questions if that part is still unclear.

Take a look at the files in https://github.com/benmaddison/rasn/tree/object-classes-ideas/examples.
I'm going to attempt to implement the AsnType, Encode and Decode traits on these, and see where I get stuck :-)

[benmaddison]

@XAMPPRocky, I have made some progress on this today.

Please take a look at the above branch, and let me know what you think?

[XAMPPRocky]

Hmmm... this is dependent on the variant of Self
// Not even quite sure how it is used, since omitting it doesn't seem to break anything!
// Field::new_required(T::Foo::TAG, T::Foo::TAG_TREE),

You'll find that in most codecs, the tag of choices should be the smallest tag of all possible variants for the purposes of canonical sorting. It might not matter in this case, but it's important in the general case for things like choices and sets, or even just optional fields in codecs like PER.

// it would be nice for this to be SequenceOf<Foo<Box>>,
// but then we have to specify the type of FooType::Foo :-(
// ideas?

I think we can achieve this with separate traits, we have an object safe trait that operates on Any and then a "type safe" version that allows you to specify the type. This is a basic generic version but you could add error handling and methods for getting the metadata like id so you can if it's the right type before setting.

const _DYN_TEST: &[&dyn ObjectSafeAccess] = &[];

trait ObjectSafeAccess {
    fn get_boxed(&self) -> Box<dyn Any>;
    fn set_boxed(&mut self, value: Box<dyn Any>);
}

trait TypeSafeRead {
    fn get_as<T: Any + Clone>(&self) -> Option<T>;
}

trait TypeSafeWrite {
    fn set_as<T: Any>(&mut self, value: T);
}

impl TypeSafeRead for &dyn ObjectSafeAccess {
    fn get_as<T: Any + Clone>(&self) -> Option<T> {
        self.get_boxed().downcast().ok().map(|v| *v)
    }
}

impl TypeSafeWrite for &mut dyn ObjectSafeAccess {
    fn set_as<T: Any>(&mut self, value: T) {
        self.set_boxed(Box::new(value))
    }
}

// There is rather a lot of duplication between this and the impl Decode for Foo<T>

I don't know if there's a way around that when writing a manual implementation, however I would love to see what you think this would look like if it was entirely declarative. Like pretend that there's a magical derive macro that implements everything we need for this, what would you want the syntax for declaring a class and objects to look like?

[benmaddison]

That's a good question.

I think I would use a function-style macro with a custom DSL rather than a derive for the info object definitions, and then extend the #[rasn(...)] attribute for the field bindings.

Something like:

info_object! {
    class FooType {
        const(unique) ID: OctetString;
        const DESCR: &'static str;
        type Foo;
    }

    instance FtBar of FooType {
        const(unique) ID: OctetString = OctetString::from_static(&[0x01]);
        const DESCR: &'static str = "Bar";
        type Foo = Integer;
    }

    instance FtBaz of FooType {
        const(unique) ID: OctetString = OctetString::from_static(&[0x02]);
        const DESCR: &'static str = "Baz";
        type Foo = BitString;
    }
    
    set FooTypeSet of FooType {
        FtBar,
        FtBaz,
    }
}

#[derive(Debug, Clone, PartialEq, Eq, AsnType, Encode, Decode)]
#[rasn(table(FooTypeSet))]
struct Foo<#[rasn(instance)] T> {
    name: Utf8String,
    #[rasn(field(id, key))]
    foo_type,
    data: T::Foo,
}

Not sure about the attribute on the generic parameter declaration... is that even legal?!

[XAMPPRocky]

Not sure about the attribute on the generic parameter declaration... is that even legal?!

The only thing not legal here is the foo_type field, and data (you need T to be T: FooType for that to work). Derive macros aren't allowed to change the definition, so it might be worth having table also be full proc macro rather than being derive based.