Difference between revisions of "Grouping of geometries"
(Massive improvements on intro and section == Heavily restricted functions ==) |
(→Awfully implemented inheritance: cleared the wikitodo) |
||
| Line 28: | Line 28: | ||
== Awfully implemented inheritance == | == Awfully implemented inheritance == | ||
| − | + | Base geometry and overrides is in principle a good idea (assuming overrides being further overridable). <br> | |
| − | + | <small>(not referring to terrible ad-hoc invented OOP inheritance like in C++)</smalL> | |
| + | |||
| + | The problem comes in once the same sub-assembly system is used in a lot of different contexts. <br> | ||
| + | When a designer can no longer check if some new changes made will fit with all the old usage contexts. | ||
| + | |||
| + | '''Long story short:''' | ||
| + | Highly desirable would be <br> | ||
| + | – semi manual backward update distribution, that is ... <br> | ||
| + | – a way to back-propagate mere notifications about propagatable changes to all (or some of) the old usage contexts <br> | ||
| + | – a software system design such that automatedly propagated changes can be very easily reverted in case they cause problem <br> | ||
| + | Groupings of geometries usually don't do that. | ||
| + | |||
| + | === Static types for safer back-propagation of new changes === | ||
| + | |||
| + | One method that can help ensuring that later changes fit old contexts is using static types. <br> | ||
| + | Groupings of geometries usually do not have these. | ||
| + | |||
| + | Though even static types have their limits. <br> | ||
| + | It is desirable that static types capture the meaning of what they describe sufficiently unambiguously. <br> | ||
| + | This is not always the case though. <br> | ||
| + | – Sometimes the meaning of descriptive types is too ambiguous to begin with. <br> | ||
| + | – Other times an initial unambiguous meaning may drift. But … <br> | ||
| + | But such that it is discovered that the new split in meaning <br> | ||
| + | must eventually be backpropagated to a subset of the old usage contexts <br> | ||
| + | withing quantity of old usage contexts that is too large for immediate manual case by case checking. | ||
== Microcomponents == | == Microcomponents == | ||
Revision as of 08:41, 11 October 2023
The grouping functionality for geometries like it is found in
many rastergraphic, vectorgraphic and 3D-modelling programs which have
a graphical user interface and mouse interaction is supposed to make the grouped things reusable.
(well and to holding things together such that they can be drag and dropped moved as a whole)
While this approach works for "simple" cases the approach fails for anything beyond that.
The problems are that:
- Groupings are basically just heavily restricted functions.
- When duplicated groupings are often irreversibly detached from the original.
- Groupings have usually no or awfully implemented inheritance.
Contents
Heavily restricted functions
Groupings have a fixed set of parameters that all are implicitly hidden in most cases.
The implicit parameters are usually only linear transformations applied to the whole grouping:
That is: translation (insertion point), scaling, rotation, sometimes shearing.
Other transformations are usually not possible.
Other transformations does not just meas simple weird (and rarely useful) nonlinear transformations like swirls and such but
General programmatic transformations changing specific details in specific ways on specific potentially highly nontrivial conditions.
Even nontrivial changes where the same "object" may end up with a completely different look.
(good abstractions ~~ high levels of data compression).
Awfully implemented inheritance
Base geometry and overrides is in principle a good idea (assuming overrides being further overridable).
(not referring to terrible ad-hoc invented OOP inheritance like in C++)
The problem comes in once the same sub-assembly system is used in a lot of different contexts.
When a designer can no longer check if some new changes made will fit with all the old usage contexts.
Long story short:
Highly desirable would be
– semi manual backward update distribution, that is ...
– a way to back-propagate mere notifications about propagatable changes to all (or some of) the old usage contexts
– a software system design such that automatedly propagated changes can be very easily reverted in case they cause problem
Groupings of geometries usually don't do that.
Static types for safer back-propagation of new changes
One method that can help ensuring that later changes fit old contexts is using static types.
Groupings of geometries usually do not have these.
Though even static types have their limits.
It is desirable that static types capture the meaning of what they describe sufficiently unambiguously.
This is not always the case though.
– Sometimes the meaning of descriptive types is too ambiguous to begin with.
– Other times an initial unambiguous meaning may drift. But …
But such that it is discovered that the new split in meaning
must eventually be backpropagated to a subset of the old usage contexts
withing quantity of old usage contexts that is too large for immediate manual case by case checking.
Microcomponents
In physical systems microcomponents could be seen as such groupings with all its detriments.
But microcomponents are low level instances of a high level abstract software representation.
Systems of microcomponents are compiled (decompressed) results of a high level highly compressed abstract software representation
that does not suffer from the "grouping"-problem.
(TODO: More investigation is needed in the microcomponent-as-group-problem direction.)
