Difference between revisions of "Grouping of geometries"
(Modularity) |
m (→Modularity) |
||
| Line 72: | Line 72: | ||
Modularity is a highly desirable property for getting comprehensible, maintainable, and scalable systems. <br> | Modularity is a highly desirable property for getting comprehensible, maintainable, and scalable systems. <br> | ||
| − | Grouping of geometries in [[ | + | Grouping of geometries in [[phase space|position space]] is not the only form of modularity though. <br> |
Groupings in higher dimensional or even abstract programmatic spaces can be just as helpful and in many cases is even much more helpful. <br> | Groupings in higher dimensional or even abstract programmatic spaces can be just as helpful and in many cases is even much more helpful. <br> | ||
When looking at the compiled down to concrete geometry result of these programmatic groupings (functional definitions) in real space <br> | When looking at the compiled down to concrete geometry result of these programmatic groupings (functional definitions) in real space <br> | ||
Revision as of 09:18, 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 and standard part crystolecules
In physical systems of gemstone based APM microcomponents could be seen as such groupings with all the detriments of groupings.
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.
Desire for standardized physical interfaces may force a bit more naive block like grouping at this particular size scale.
But both at smaller and bigger scales things may turn out much more interwoven and complex.
Standard crystolecules also have a strong group-of-geometry character.
(TODO: More investigation is needed in the microcomponent-as-group-problem direction.)
Modularity
Modularity is a highly desirable property for getting comprehensible, maintainable, and scalable systems.
Grouping of geometries in position space is not the only form of modularity though.
Groupings in higher dimensional or even abstract programmatic spaces can be just as helpful and in many cases is even much more helpful.
When looking at the compiled down to concrete geometry result of these programmatic groupings (functional definitions) in real space
then one can see that interfaces may be highly variable complexly intermediating and not even spacially singly connected.
Kinda like like shoes, bikinis, and the sheets of a newspaper are one thing that is multiple things.
Quick recomposability of larger structures makes interfaces
that are ad hoc modified to the problem at hand much more feasible.
The actual interfaces remain hidden in the abstract programmatic space before compilation.
See: Modularity and abstraction
