4 ms·

Thanks for the informative comment. > So it would automatically realize that the function called the close method, and infer the appropriate type. So, if i un

Thanks for the informative comment. > So it would automatically realize that the function called the close method, and infer the appropriate type. So, if i understand this correctly, OCaml would infer that the function takes "an object with write() and close() methods" because it uses both methods in its definition. That's reasonable. But wouldn't that prevent it from accepting objects that don't have a close() method? Wouldn't the proper type for the parameter of this http library be something like "an object with a write() method or (an object with write() and close() methods)" (i should have used another notation for this hehe)? I think the biggest problem in this case is no so much the weakness of Go's type system, but the design decision of mixing two different behaviours (that require two different type signatures) in the same method in the http library. It seems there should be one method that takes a Reader and only calls Read() and another method that takes a ReaderCloser and calls both Read() and Close(), it can even delegate to the first one (assuming, of course, that Go accepts Reader as a valid subtype of ReaderCloser (i would hope so!)).

exch 13y ago
> (assuming, of course, that Go accepts Reader as a valid subtype of ReaderCloser (i would hope so!)). Yes it does: http://play.golang.org/p/OnBotL9zfF http://play.golang.org/p/OnBotL9zfF
- epidemian 13y ago
  Thanks for the example. Playing with the example a little bit left me with a nice feeling about Go's structural typing: - Passing a ReaderCloser reference to a function that expects a Reader is possible: http://play.golang.org/p/PZCKvmp5Sj http://play.golang.org/p/PZCKvmp5Sj - Composing interfaces, though very useful, is not required in order to make one a proper subtype of the other: http://play.golang.org/p/fXn0zzM60D http://play.golang.org/p/fXn0zzM60D
andolanra 13y ago
You're right; OCaml would have to supply two different functions, one that takes an object that exposes < close : (); write : string -> (); .. > and another that takes < write : string -> (); .. >. Reproducing the Go system would require the ability to, at runtime, see whether an object of type < write : string -> (); .. > can be downcasted to < close : (); write : string -> (); .. >, which would require more runtime type information than OCaml currently supplies. Some people have made proposals to implement such downcasting (throwing an exception if the downcast fails), which would permit the Go-like implementation, but as far as I know, such proposals haven't been met with much enthusiasm.
- epidemian 13y ago
  Thanks for the examples of record types in OCaml. > but as far as I know, such proposals haven't been met with much enthusiasm. Well, if the proposed use cases are similar to this http Go library, then i think i can see why that's the case. As just adding a close: () method to a type could mean that code that uses that type now behaves differently.
deleted 13y ago
[deleted]

exch 13y ago

> (assuming, of course, that Go accepts Reader as a valid subtype of ReaderCloser (i would hope so!)). Yes it does: http://play.golang.org/p/OnBotL9zfF http://play.golang.org/p/OnBotL9zfF

epidemian 13y ago
Thanks for the example. Playing with the example a little bit left me with a nice feeling about Go's structural typing: - Passing a ReaderCloser reference to a function that expects a Reader is possible: http://play.golang.org/p/PZCKvmp5Sj http://play.golang.org/p/PZCKvmp5Sj - Composing interfaces, though very useful, is not required in order to make one a proper subtype of the other: http://play.golang.org/p/fXn0zzM60D http://play.golang.org/p/fXn0zzM60D

andolanra 13y ago

You're right; OCaml would have to supply two different functions, one that takes an object that exposes < close : (); write : string -> (); .. > and another that takes < write : string -> (); .. >. Reproducing the Go system would require the ability to, at runtime, see whether an object of type < write : string -> (); .. > can be downcasted to < close : (); write : string -> (); .. >, which would require more runtime type information than OCaml currently supplies. Some people have made proposals to implement such downcasting (throwing an exception if the downcast fails), which would permit the Go-like implementation, but as far as I know, such proposals haven't been met with much enthusiasm.

epidemian 13y ago
Thanks for the examples of record types in OCaml. > but as far as I know, such proposals haven't been met with much enthusiasm. Well, if the proposed use cases are similar to this http Go library, then i think i can see why that's the case. As just adding a close: () method to a type could mean that code that uses that type now behaves differently.

deleted 13y ago

[deleted]