4 ms·

types are not interfaces. interfaces describe behavior, types describe shape and structure. the difference is subtle but important.

by tinix 2y ago

Iceland_jack 2y ago
In Haskell behavour is type-directed (type classes) and they describe both.
BugsJustFindMe 2y ago
> 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".
- CyberDildonics 2y ago
  Shape and structure are behavior. 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.
  - BugsJustFindMe 2y ago
    > 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.
    - CyberDildonics 2y ago
      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. Memory layout has nothing to do with type, So float, int, unint64, int8 and a vector/array don't have specific memory layouts? the semantic logical layout and form represented by the bits This is nonsense and doesn't mean anything.
      - BugsJustFindMe 2y ago
        > 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?
        CyberDildonics 2y ago
        The memory layouts don't need to be known to the user. This isn't relevant one way or another. Different hardware architectures can have the concept of floats and ints This also isn't relevant. Data types aren't expected to be cross platform unless they are specifically made for that, like file formats. Funny, I recall you not very long ago saying "interfaces describe behavior, types describe shape and structure" I never said that. Also just because two things work together doesn't mean they are the same thing.
        BugsJustFindMe 2y ago
        > > The memory layouts don't need to be known to the user. > This isn't relevant one way or another. What needs to be known to the user of an interface is the most relevant aspect of describing that interface. > Data types aren't expected to be cross platform unless they are specifically made for that, like file formats. It's going to be difficult to reconcile that position with https://en.wikipedia.org/wiki/Abstract_data_type https://en.wikipedia.org/wiki/Abstract_data_type 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.
klysm 2y ago
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.
- tinix 2y ago
  fair, maybe i should have said "protocols define behavior" instead of interface
LudwigNagasena 2y ago
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.

types are not interfaces. interfaces describe behavior, types describe shape and structure. the difference is subtle but important.

by tinix 2y ago

types are not interfaces. interfaces describe behavior, types describe shape and structure. the difference is subtle but important.

Iceland_jack 2y ago

In Haskell behavour is type-directed (type classes) and they describe both.

BugsJustFindMe 2y ago

> 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".

CyberDildonics 2y ago
Shape and structure are behavior. 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.
- BugsJustFindMe 2y ago
  > 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.
  - CyberDildonics 2y ago
    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. Memory layout has nothing to do with type, So float, int, unint64, int8 and a vector/array don't have specific memory layouts? the semantic logical layout and form represented by the bits This is nonsense and doesn't mean anything.
    - BugsJustFindMe 2y ago
      > 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?
      - CyberDildonics 2y ago
        The memory layouts don't need to be known to the user. This isn't relevant one way or another. Different hardware architectures can have the concept of floats and ints This also isn't relevant. Data types aren't expected to be cross platform unless they are specifically made for that, like file formats. Funny, I recall you not very long ago saying "interfaces describe behavior, types describe shape and structure" I never said that. Also just because two things work together doesn't mean they are the same thing.
        BugsJustFindMe 2y ago
        > > The memory layouts don't need to be known to the user. > This isn't relevant one way or another. What needs to be known to the user of an interface is the most relevant aspect of describing that interface. > Data types aren't expected to be cross platform unless they are specifically made for that, like file formats. It's going to be difficult to reconcile that position with https://en.wikipedia.org/wiki/Abstract_data_type https://en.wikipedia.org/wiki/Abstract_data_type 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.

klysm 2y ago

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.

tinix 2y ago
fair, maybe i should have said "protocols define behavior" instead of interface

LudwigNagasena 2y ago

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.