> interfaces describe behavior, types describe shape and structure
Shape and structure are behavior. There's more to behavior than "abstractly produces X result". Behavior is "produces X result in Y form given Z in W form".
They shouldn't be. Conflating two things that can be separated is just compounding complexity. You don't need to know how a database lays out memory or the structure behind a web server.
> You don't need to know how a database lays out memory
You do, however, need to know what logical columns are in a table and the types of those columns to be able to effectively query against the table. And you need to know what the types of the inputs to a query wrapper function are to be able to call it properly.
Memory layout has nothing to do with type, because physical memory layout is completely separate from the semantic logical layout and form represented by the bits. You now appear to be the one conflating two unrelated things.
That something is treated as an integer fundamentally matters to its use. That the thing comprises some number of adjacent bits in big/little-endian arrangement is a very unrelated implementation detail.
> So float, int, unint64, int8 and a vector/array don't have specific memory layouts?
The memory layouts don't need to be known to the user. Different hardware architectures can have the concept of floats and ints and code can be written using them the same way while the underlying representations are distinct. I promise that IEEE754 is not the only way to represent floating point values handed down from god to man on a golden scroll.
> > And you need to know what the types of the inputs to a query wrapper function are to be able to call it properly.
> That's the interface.
Funny, I recall you not very long ago saying "interfaces describe behavior, types describe shape and structure". Now you acknowledge that the interface necessarily includes the types of the arguments?
Data types can optionally specify machine representation but need not. They specify behavior (i.e. possible values and operations) first and foremost. In programming, nearly every use of data type is in the abstract, entirely separate from its hardware representation. The "Int", the "Bool", the "2", the "UTCTime" being specified in TFA don't care about bit arrangements. They're describing valid values and operations, not hardware.
> I never said that.
You're right. Apologies. It was the other poster at the top of the thread. But it still seems apt to the thread and to your specific portrayal.
Interfaces are usually understood as a subset of types. Interfaces specifically describe method signatures. Nevertheless, the distinction is murky because any structure can be interpreted in terms of getters and setters which can be considered methods.
Depends on the language. In typescript and interface can absolutely encode shape. In C# you can encode shape in interfaces via properties. Interfaces don’t even describe behavior, it’s just that we typically associate them with a man implicit contract. Strictly speaking they are just a shape.
interfaces describe behavior, types describe shape and structure. the difference is subtle but important.