Objects in their own rights

language design
1

(aka Hiding representation details from concrete types or ideas themselves)

Hi, I appreciate the current design, which explicitly exhibits the ingredients and components (like Rc, Box, RefCell, etc) within concrete types, which is very good.

However, i think that in more complex systems, there shall be some ergonomic way to hide these details from the “concepts” for some domain objects. Shareable and Mutable should be its property, but other than that, whether there’s Arc or Mutex behind those ideas should be hidden some way. For example, When we implement Deref<T> for Rc<T> we’re actually providing them a way to access the inner data, i.e. operate through the “eggshell”. However, when there’s more than one level of “eggshell”, things become worse…

For example, it’s currently quite frustrating to argue about Arc<Mutex<T>> or Weak<Trait> in the codes. Especially in the later case, where we’re struggling to hide what it is with trait objects but still leave its shareable state hanging outside…

I wonder if people’re feeling the same.

2

I doubt “objects” usually refers to abstracting what smart-pointers do, but ignoring that…

I never thought about the details but I’d assume associated type constructors and/or HKT to enable better alternatives to the current zoo of Deref, AsRef, Borrow, etc. At least we should figure out how far associated type constructors take us that direction.

I mostly just try to stick to working with borrows as much as possible so that I can change the actual smart pointer type in fewer places, so sometimes its actually an Arc but all the logic works with &MyStruct and MyStruct contains some RwLocks.

3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.