I recently found out that OOP classes turn out to be F-coalgebras:
The coalgebraic perspective on objects and classes in object-oriented programming is elaborated: objects consist of a (unique) identifier, a local state, and a collection of methods described as a coalgebra; classes are coalgebraic (behavioural) specifications of objects. The creation of a 'new' object of a class is described in terms of the terminal coalgebra satisfying the specification
In here, https://stackoverflow.com/questions/16015020/what-does-coalgebra-mean-in-the-context-of-programming the top answer's author describes this class
class C
private
x, y : Int
_name : String
public
name : String
position : (Int, Int)
setPosition : (Int, Int) → C
as a coalgebra like this:
data C = Obj { x, y ∷ Int
, _name ∷ String }
and the public methods like this
position ∷ C → (Int, Int)
position self = (x self, y self)
name ∷ C → String
name self = _name self
setPosition ∷ C → (Int, Int) → C
setPosition self (newX, newY) = self { x = newX, y = newY }
My question is this: Is it possible to actually define the public methods as an F-algebra?
Would this make an OOP class actually a bialgebra like described in here? https://www.researchgate.net/publication/220976988_Categorical_Programming_with_Abstract_Data_Types
The main idea is to represent an ADT by a bialgebra, that is, an algebra/coalgebra pair with a common carrier
Which would explain why so often classes are used to define abstract data types in OOP languages?