[terminology] map(), but not really

I have a crate that implements a special queue. I also have another crate that turns that special queue into a special channel.

The queue has a magical context within it that can be accessed via references:

impl SpecialQueue {
  fn controller(&self) -> &C {
     &self.ctrl
  }

  fn controller_mut(&self) -> &C {
     &mut self.ctrl
  }
}

I want the user to be able to access these via the channel end-points. However, in these cases the ctrl lives behind a Mutex. I thought I'd allow the user to access ctrl via a closure instead:

impl SpecialChannelSender {
  pub fn map_ctrl<F, R>(&self, f: F) -> R
  where
    F: FnOnce(&Ctrl) -> R
  {
    let inner = self.inner.lock();
    f(&inner.ctrl)
  }

  pub fn map_ctrl_mut<F, R>(&self, f: F) -> R
  where
    F: FnOnce(&mut Ctrl) -> R
  {
    let inner = self.inner.lock();
    f(&mut inner.ctrl)
  }
}

While in a sense I guess it is a "map", I can't help feel that a map is more focused on the actual mapping from an input to an output (and is also expected to be an Iterator?), while this is more of a "I just want access to the guts of this thing that's behind a lock" (it may just reset variables in Ctrl and not return (i.e. map to) anything other than the unit type (which I guess technically is still a map)). Is there a more suitable/established terminology for this pattern?

What you write reads like describing lending and rust typically used with to prefix functions that take a closure that gain access.

2 Likes