Rust::com Field and Method Rust Design and Example of APIs usage

[bharatGoswami8]

For Method and Field Design following things added -

• Field subscribe/receive (FieldSubscriber, FieldSubscription traits): a consumer can subscribe to a field, receive value updates.

• Field publish/update (FieldPublisher trait): a producer can update() a field value, register a set handler (called when a consumer sets the field), and register a get handler.

• Field get/set on the consumer side reuse Method infrastructure: get_{name}() / set_{name}() async helpers are generated by the interface! macro using MethodCaller there is no separate field-get/set trait.

• Method traits (MethodHandler for producer, MethodCaller for consumer): supports up to 8 arguments via tuple-based arities, with both copy and zero-copy call paths.

• Type-state derive macro (#[derive(TypeStateValidator)]): generates compile-time state transitions so a producer struct cannot call offer() before all fields are initialized and all handlers are registered.

• Interface macros split into producer and consumer: interface_producer_macros.rs generates the skeleton struct with all fields/methods/events; interface_consumer_macros.rs generates the proxy struct.

• Runtime stub added to build the APIs example usage.

• Example app with field_producer.rs, field_consumer.rs, method_producer.rs, method_consumer.rs modules showing the API usage end-to-end.

• Design documents and diagrams for both Field and Method architecture added.

#579

[LittleHuba]

Putting to draft since state is not ready for review.

[bharatGoswami8]

Putting to draft since state is not ready for review.

Addressed all the clippy and design comment.

[darkwisebear]

(Applies to all method declarations) For the sake of symmetry I would vote for a slightly different syntax:

Suggested change

	update_tire_pressure(Tire) -> (),
	update_tire_pressure: Method(Tire) -> (),

This resembles Fn bounds and should be familiar to Rust developers. In addition, this makes the declaration look similar to fields and events.

[bharatGoswami8]

Yes agreed, updated macro signature for method.

[darkwisebear]

Imo the examples aren't that compelling as the method calls declared here are very close to similar methods from fields (update_... and get_...). It would be better if there were a method that are quite different (something like calculate_hash_for: Method(&[u8], hash_type: HashType) -> u32).

[bharatGoswami8]

Updated example and macro configuration.

[darkwisebear]

How would that work? In line 69 it looks like a callable, but here it looks like an object. Mixing this is afaik only possible by implementing an unstable Fn trait. Or did you find another solution for that?

[bharatGoswami8]

We are not using the unstable Fn trait. update_front_tires_pressure is an object (struct field) we get from the consumer struct, and a method with the same name is generated in the consumer's impl block by our interface macro.
And the underlying invocation happens using static dispatch via generic trait bounds (MethodCallInput), compiler generates a separate concrete function per type combination and picks the right one for each call site while compiling, not dynamic (dyn) trait dispatch, as shown in the example.

// A "dispatch" trait
trait CallMethod<Ret> {
    fn dispatch(self) -> Ret;
}

// Impl for "copy path"
impl CallMethod<String> for i32 {
    fn dispatch(self) -> String {
        format!("copy path, value = {}", self)
    }
}

// Impl for "zero-copy path"
struct Ptr(i32);
impl CallMethod<String> for Ptr {
    fn dispatch(self) -> String {
        format!("zero-copy path, ptr value = {}", self.0)
    }
}

struct Caller;

struct Consumer {
    // field named the same as the method below
    my_method: Caller,
}

impl Consumer {
    // generic inherent method, same name as the field
    fn my_method<A>(&self, arg: A) -> String
    where
        A: CallMethod<String>,
    {
        arg.dispatch()
    }
}