Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Types as Interfaces

two-wrongs.com

Post reply on HN
Print view View original

21–30 of 197 posts

Re: Types as Interfaces

#21

Post by lenkite »

posix_monad wrote: post #3

MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…

Not sure whether this is what you intended, but Go structs can embed other structs

    type Foo struct {
     foo int
    }

    type Bar struct {
     bar string
    }

    type FooBar struct {
     Foo
     Bar
    }

Re: Types as Interfaces

#24

Post by jddj »

brabel wrote: post #2

Is this something professional programmers are having trouble with?? This is the kind of problem you face in your first year working, no? I am honetly curious what others think. Do you have trouble deciding when to use an interface (assuming your language has that), or a type wrapper (I don't think that's the brightest idea), or a function to extract the field to sort by (most languages do that)??

Your confidence that there is an obviously optimal way to model something reads as either brilliance or hubris and brilliance is a lot rarer.

Typically there are subtle trade-offs and compromises which only prove themselves to be useful/detrimental as the software changes over time. You can place bets based on experience but you can only really be cocky about your choices when looking back not looking forward

Re: Types as Interfaces

#26

Post by sltkr »

lenkite wrote: post #21
posix_monad wrote: post #3

MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…

Not sure whether this is what you intended, but Go structs can embed other structs type Foo struct { foo int } type Bar struct { bar string } type FooBar struct { Foo Bar }

This doesn't function as an interface though. You cannot pass a FooBar to a function that expects a Foo, for example, and although you can fairly easily reference the Foo-part of a FooBar instance (`foobar.Foo`) there is no way to pass e.g. an array of FooBar instances to a function that takes a slice of Foo[] as its argument. That's the problem to be solved.

Re: Types as Interfaces

#27

Post by PoignardAzur »

posix_monad wrote: post #3

MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…

Ok, but why?

I like the beauty of an expressive type system as much as the next guy, but is there any scenario where:

    type FooBar = mergeMaps Foo Bar
Is better for solving real-world problems than

    type FooBar = { "_foo", Foo, "_bar", Bar }
or whatever?

Re: Types as Interfaces

#28

Post by auggierose »

Indeed, TypeScript can do exactly this and more, without much ceremony:

    type FooBar = Foo & Bar
I doubt you will find a language where it is less clunky.

Edit: Oh, I typed this on mobile, this was supposed to be a comment on another comment by posix_monad.

Re: Types as Interfaces

#29

Post by octachron »

derdi wrote: post #11
posix_monad wrote: post #3

MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…

OCaml's first-class modules allow you to do this: https://ocaml.org/play#code=bW9kdWxlIHR5cGUgRk9PID0gc2lnCiAg...

Ocaml object system can also achieve this in a quite lightweight way

    type foo = 
    type bar = 
    type k = 
    type u = 
    let f (x: ) (\* the type annotation is not needed \*) = x#m

Re: Types as Interfaces

#30

Post by sltkr »

brabel wrote: post #19
posix_monad wrote: post #3

MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…

The Ceylon language allowed you to do that sort of thing with types. If you "added" two maps together of types `Map ` and `Map `, you would get back a `Map ` (or, equivalently, `Map | Map `). But for some slightly complex reasons, most language designers find adhoc union types (which are required for this to work) a bad idea. See the Kotlin work related to that, they explicitly want to keep that out of the language (…

> If you "added" two maps together of types `Map` and `Map`, you would get back a `Map` (or, equivalently, `Map | Map`).

But these are obviously not equivalent: the first type is a map where all values are either strings or ints, and the second one is either a map where all values are strings, or all values are ints.

If that's confusing, consider: {foo: 1, bar: "2"}. It satisfies `Map` but not `Map | Map`.

(In fact, the latter is a subtype of the former.)

P.S. You also seem to have misunderstood the toplevel comment about modeling record types as maps, as being about typing maps that exist in the language.

Post reply on HN