Abstraction (the many meaning) (Select relevant info (Stepanov (math to…
Abstraction (the many
Graph and DFS... foldable or iterable... depends on the idiomatic usage of the language
RGBA color... abstract way to encode the color... make it generic and only ask for constraints upon use cases... leads to types pretty empty... behaviors on them is what counts
Indexing into a container... should work for map or vector... abstraction for something that can be indexed (with index type being a dpdt type... not like Haskell, but like Clojure)
Means of abstraction
Functions, HOF (better than adhoc for flexibility - but less practical when you need type associated to fct - example of à tree with typeclasses for routing)
Ad-hoc polymorphism (knowledge required)
Parametric polymorphism (no knowledge required)
Data is powerful abstraction: Abstract how it is used (Spec vs how), when it is used (stored), allows inspection, is very easy to understand (but is not supported in Typed Lang)
Forms of abstraction
& selection of abstraction
This defines a
point of connection
. Anything that complies can plug into it. Call with right arguments, support some interface, obey these laws...
is how to
comply to an abstraction,
and the incentive to comply to abstractions to make for instance a type à Monoid in order to profit from the rich set of tools available on it.
Depend on language
The mechanism of the language are based on some things, primarily names. They imply a way to signal something comply with an abstraction: arguments to pass, interface to implement, members to contain...
The abstraction is a reduction of information, a selection of the information needed to handle a task. Language constructs allow to reify these in the form of requirements, arguments to a function, etc.
Are there two meaning?
cause dev think
virtual... they think dynamically switchable
point of connection
from the fact we reduced the selected characteristics
the process of taking away info
the resulting abstraction
Functions (hide details), classes, type parameters (holes with or without constraints) or data (recipe, as code is).
Each way to encode an abstraction has its implications on how to use it... and it depends on what you abstract.
Program to abstraction
About point of connection...
Let you select one point of connection for a concept:
below it you can unify a lot of models
you rarely program with the point of connection (wrappers)
basically, reduce the graph to a point to build a new forest on it
example of iterators, foldable... dfs allows to put the graph in it but you rarely program with barre iterator, you build range and algo
Later something assembles the pieces
State your dependencies (constraints) - the relevant parts - minimal
Do not care about layer....
(interface/ concept /
point of connection)
Easy to add superfluous constraints. Stay simple, with idiomatic Data structure for instance, minimize constraints for the user, and leads to better benefit over cost for user (bad example : unneeded inheritance - ex of data for mig step - custom vector wrapper - types non regular...)
The more constraints, the less models, the more power they offer, the more difficult to grasp they are
Most abstraction are in fact directly pointing at an implementation (example of virtual getters returning const&)
The more constraints, the less model there are
Look at the filtered characteristics (relevant) and therefore the number of constraints imposed
Something not really hidden
Assumptions broken: example Monoid color
So more like graph (and à DI
framework is a way to assemble
Point of connection
The shape also contains properties (it is mostly not about the syntax... name args, but about the constraints)
Like a hole to accept à given shape
Which any model that satisfies can plug to
An abstraction defines a concept
Select relevant info
(math to gen programming): two steps for algorithms, first make them work, then figure out on what kind of stuff they work (abstraction)
: on my color I only care about it being à Monoid in this specific case (defining Monoid for image), to define the image though, I need to know nothing...
Pick some characteristics as relevant
of an implementation or some data... ignore others
Whether or not it is good depends on what you erase (erasing the components of an average... aggregates of flow... not good to erase USER data)
AST keeps info (transformation) vs
Money map erase info (abstraction)
Monoid... how things are built
The generalized process (data, ast, interpreter) - interpreter is just specific kind of function... data IN, effect OUT
The process of sequencing something (Monad)
The process of building something (Monoid, Cat)
The choice of implementation (which concrete class,
how to do something)
Interconnexion (mediator abstracts this)
The choice of representation (data abstraction, polymorphism ?) - but in the end, these are the functions to perform in the data that counts - constraints on a type
The process (steps) to do something (function)