Hacker News Reader

Comment by wyager | Hacker News Reader

The author seems to be confusing typeclass composition with OOP. They are only topically similar. (Personal opinion; typeclass composition is more principled than OOP, but a bit more rigid, which he is running into.)

There are several good ways to do this with type classes/traits. One way is to write a function

font_size : Widget t => t -> FontSize

And then in the widget definition have the "internal" font size defined, which the author seems to be assuming the existence of for some reason.

Additionally, in a language like Rust with ADTs, there's no good reason to return negative numbers to signify things like a missing font. He should be returning Maybe FontSize if he wishes to signify that an object may not contain a font size.

View on HN

> The author seems to be confusing typeclass composition with OOP.

I agree and would like to expound on that idea. One of my biggest frustrations with inheritance in traditional statically typed languages (I program in C++ for a living) is that inheritance is performing two functions at once: code reuse and typing. Confusing the two seems to cause a lot of pain. Inheritance as a type system is describing the kinds of things the object can do. Inheritance is (usually) a sufficient condition to say that the types can be used interchangeably. Making inheritance the only way to express the type information often forces some very unfortunate code.

The author is trying to use traits as a code re-use mechanism. He wants the trait to be able to see into the implementation and be a function of the implementation's private data. If that were allowed, that would invite all of the pain of inheritance for that kind of trait. Types with a different internal implementation would end up being awkward at best.

This sounds like a failure of the Rust documentation.

The documentation is supposed to tell you what the language is, not exhaustively detail everything the language is not.

No, it's supposed to teach people how to use the language. When a large fraction of your user base will be bringing a specific skill set, then you should generate documentation aimed at translating those skills!

You've described tutorial, not a language documentation set.

Exactly, you can't expect to "port" code across from languages in different paradigms without rethinking the design a little bit.

I really like traits/type classes over OOP-style type systems but sometimes it causes a bit of impedance mismatch.

Reply on news.ycombinator.com