I am writing business line applications - I don't have much need for "generic" functions like outlined in the article. My framework/language provides for example generic .Sum() I could use if I implement specific interface.
But usually I have to make specific sum and put it in database or in the interface.
Like I need to sum age or sum prices or sum amount of items in inventory - and I have to show these in the interface. I think it is quite BS to say there can be "generic" data structure and "generic" functions in context of business line application.
Other stuff I was doing was warehouse automation system and if I had X,Y,Z coordinates I had these in generic data structure named Coordinates - but any function that was going to do anything with coordinates had to be implemented in the context of machine. For example lift should never operate on X cooridinate I could calculate distances - but then there was never use case to calculate distance between machines because these had static access points and one would calculate distances to these access points only.
In OOP data and method are unionized into primitives that form the basic building blocks of your program.
This is unique to OOP. It must be the definition. Defining it in terms of message passing, encapsulation and inheritance are not as good because these concepts are used in other paradigms as well.
const p = Point(3, 5)
p('getX') // 3
p('up', 11)('toString') // "Point(3, 16)"
const Point = (x, y) => (method, ...args) => {
switch (method) {
case 'getX': return x;
case 'getY': return y;
case 'toString': return `Point(${x}, ${y})`
case 'up': return Point(x, y+args[0]);
// ...
}
}
(unfortunately statically typing this statically requires... some work, either sth like [typescript overloads + literal types] or full on dependent types)At best what I've done here is eliminate some of the vagueness surrounding the definition, which is really all that's needed in most cases.