"Advanced"

[phil-levis]

We now have two "Advanced" operations in Tock:

• The hil::uart::ReceiveAdvanced trait
• process_utilities::load_processes_advanced

I'd like to argue that we avoid the use of Advanced as a naming scheme. It's not very descriptive; these two particular use cases have almost nothing in common, yet we see the term used in both. For the UART case, the trait provides an additional method, so it's more like an extension in Rust terminology (e.g., slice_ext). In the process case, it's a lower-level method that has more arguments, which the standard load_processes invokes with some defaults. So it's more like the relationship between fork and clone; the former is semantically a wrapper around the latter.

In uart, I'd argue this should be ReceiveWithTimeout. It's what the trait does.

For load_processes_advanced, I can imagine two paths:

1. We really want load_processes_advanced to be the basic function, which then different wrappers apply default policies to. In this case, we should name load_processes_advanced to load_processes and load_processes should be load_versioned_processes or load_processes_default.
2. We really want load_processes to be the basic function, and we'll extend load_processes_advanced as more options come up, but we really don't imagine multiple policies being around. In this case I wonder why we have this. In this situation, load_processes_advanced should not be public, and instead we should just add wrappers that call with the different parameters we expect. E.g., load_processes and load_processes_ignore_version both invoke the non-pub method load_processes_internal.

@bradjc I'm especially interested in what you think about this.