Rust_observable

code review
1

I published it at 0.1.1

rust_observable provides an Observable type used to model push-based data sources. It always uses atomic references, allowing it to be passed to other threads. It is based on a TC39 proposal.

The observer! macro constructs an opaque Observer . You can also implement your own observer type if desired.

Requirements:

  • The Rust standard library (std).
2

From a quick glance:

  • have you considered running clippy?
  • I see a lot of function take Arc<dyn Something> or Box<dyn Something> as input. Have you considered making them generic on T: Something and then wrapping it in an Arc/Box internally? This way the caller would be able to avoid writing the Arc::new/Box::new manually.
    • Doing this for Observer's fields would also allow you to avoid having to use the observer! macro
3 Likes
3

@SkiFire13 I wasn't aware of clippy, it helped factorize the code a bit!

I attempted to remove Arc from the Observable constructor (now just Observable::new(|observer| { Arc::new(cleanup_fn) })), but couldn't take it out of the cleanup callback because I don't want to add a generic parameter to Observable (even if it's inferred). I've struct Observable<T, Error = ()>; as you can see Error is trailling. And Rust sometimes you'll have to specify all generic parameters, so an additional _ portion for the Cleanup can be confusing?

Sadly the Rust's object initializer currently doesn't allow omitting fields unless using ..Default::default(), which is verbose. Someone proposed .. as an alias to that I think.

4

Can't you just add a generic parameter to Observable::new? Something like (not tested):

fn new<F, G>(subscriber: F) -> Observable,<T, Error>
where
    F: Fn(SubscriptionObserver<T, Error>) -> G + Send + Sync + 'static,
    G: Fn() + Send + Sync + 'static
{
    Self { observer: Arc::new(|subobserver| Box::new(subscriber(subobserver))) }
}

I see that you used trait aliases, which are an unstable feature. This means that a nightly compiler is required, you should add this to the requirements, since unless specified it's assumed a project is compatible with the latest stable compiler.

1 Like
5

Your example just missed a move. Now, yes, no Arc involved anymore