Rationalize naming of `compute_` methods in `BaseProcessor`

[PierreRaybaut]

✨ Rationalization of BaseProcessor method names for core processing types

📌 Motivation

The BaseProcessor class in DataLab provides a set of generic methods that implement core data processing patterns (e.g., one input ➝ one output, multiple inputs ➝ single output, etc.). These methods were historically named using a numerical convention such as compute_11, compute_10, compute_n1, and compute_n1n.

While functional, this legacy naming:

• lacks semantic clarity (compute_n1n is particularly ambiguous),
• does not clearly reflect input/output arity or selection behavior,
• is not alphabetically cohesive beyond the shared compute_ prefix,
• and limits future extensibility (e.g. for ternary or generative processing types).

This issue proposes a new clear and extensible naming convention, directly based on input/output signatures and selection multiplicity semantics.

---

✅ Proposed naming convention

Each generic method is now named using the pattern compute_X_to_Y, where:

• X is the number of inputs (which may include binary pairings),
• Y is the number of outputs.

This convention supports both multi-selection (e.g. applying an operation to k objects) and pairwise processing (e.g. applying a binary operation between two matched lists of objects).

Processing types

Method name	Signature	Multi-selection support	Description
compute_1_to_1	1 ➝ 1	k ➝ k	Single-object transformation (e.g. normalization, FFT, filtering)
compute_1_to_0	1 ➝ 0	k ➝ no output	Analysis or measurement (e.g. statistics, peak detection) without new object
compute_1_to_n	1 ➝ n	k ➝ k·n	One input produces multiple outputs (e.g. ROI extraction)
compute_n_to_1	n ➝ 1	n ➝ 1 n ➝ n (pairwise mode)	Aggregation of multiple objects (e.g. sum, mean), supports pairwise variant
compute_2_to_1	1 + 1 ➝ 1	k + 1 ➝ k n + n ➝ n (pairwise mode)	Binary operation between an object and an operand; supports pairwise

---

🔁 Mapping with previous method names

Legacy name	New name	Notes
compute_11	compute_1_to_1	One-to-one transformations
compute_10	compute_1_to_0	Measurement/analysis with no object output
compute_1n	compute_1_to_n	Multi-object generation from single input
compute_n1	compute_n_to_1	Aggregation across objects
compute_n1n	compute_2_to_1	Now unified; supports both single and pairwise modes

---

⚠️ Breaking change

These methods are internal or only intended for advanced developers (e.g. plugin authors or macro-command developers).
Backward compatibility will not be maintained, as the renaming has no impact on public or user-facing APIs.

All internal usage (including within SignalProcessor, ImageProcessor, plugins, and macros) will be updated accordingly.

---

📚 Next steps

• Rename all generic methods in BaseProcessor
• Update all subclasses (SignalProcessor, ImageProcessor, etc.)
• Refactor plugins and macro-commands using these methods
• Document the new processing types in the developer documentation

---

🔄 Benefits

• 🧠 Clarity: method names clearly reflect input/output behavior.
• 📐 Simplicity: removes unnecessary terminology (map, reduce, etc.).
• 🧩 Extensibility: supports future types like compute_0_to_1, compute_n_to_n, etc.
• 📁 Consistency: all generic methods begin with compute_, aiding sorting and readability.
• 🔧 Better tooling: enables automation for menus, visual pipelines, and API generation.

---

Feedback and suggestions are welcome before finalizing the migration.