1. 10
  1.  

  2. 16

    However, a trait has no knowledge of the underlying implementation. So a trait can define abstract functions, but can’t access any underlying fields.

    Let that sink into you. My first reaction to this was “Sorry, what?!”. While there are valid criticisms against OOP, to offer this as a solution is just silly.

    This seems like both a misunderstanding of what is offered and traits do. Interfaces in Java have no knowledge of the underlying implementation and neither does an ABC: you can’t use fields you don’t declare in the ABC in methods declared in the ABC. Traits are also not really a replacement for OOP – it is rather that, sub-typing is simply not offered. The idea is to use traits (interfaces) for polymorphism exclusively.

    Some of the author’s points about having to redeclare all the fields as methods (more or less) and then allow them to be public is understandable. I’m not sure that all the methods have to be public but it might be hard to make them private. Similarly, it might be hard (or impossible) to split a trait into public and private parts and use the private part from the public part.

    However, truth be told, providing an implementation for all types implementing a trait seems like something that should be done with a generic function.

    1. 2

      Some of the author’s points about having to redeclare all the fields as methods (more or less) and then allow them to be public is understandable. I’m not sure that all the methods have to be public but it might be hard to make them private. Similarly, it might be hard (or impossible) to split a trait into public and private parts and use the private part from the public part.

      This (by the way) the way Ruby does it, which follows the uniform access principle. It just provides sugar to declare a method of the same name for a field.

      You don’t need all methods to be public, the trait providing the field access must be.

    2. 14

      I’ve never written a lick of rust. I basically understand the premise. That said, I can’t help but get the impression the author must step further back from the existing C++ implementation to rethink about how the functionality might be implemented anew in rust.

      1. 7

        It’s kind of a ridiculous rant, but it is good to think of it as a case study in what it looks like to fight a language/paradigm. The computer almost always wins, because it is infinitely patient/pedantic.

        Frankly, these sorts of experiences are usually the most edifying for me. My recommendation to the author is to suck it up and keep at it. Everyone goes through this and it’s how you learn deeply.

        1. 3

          While it is true that this is how you learn, the question is whether you want to learn. To quote OP, “I sincerely hope that people continue to use and improve Rust. But I want to write games. Not wrestle with the compiler to make the language more favourable towards my goals.”

          And some people feel while it is reasonable to ask users to learn new idioms in a new programming language, it is not reasonable to ask users to, say, “give up OOP”. In this case, Rust lacks inheritance as in subtyping between struct types, and to some people this is not acceptable, as in “I don’t want to learn any programming language which lacks that”. But that doesn’t sound very good, so the usual expression is “structural inheritance is absolutely necessary to do GUI (or something else), so Rust should add it”.

          And it is true all mature GUI systems do use structural inheritance, so it is hard to refute. So the one side says “I don’t want to wrestle with the language to do GUI”, and the other side replies “Did you mean you don’t want to wrestle with the language to do GUI, with the constraint that you program exactly as you programmed in your old language?” And the reply is “No, I mean doing GUI, not doing GUI the same old way. Doing GUI requires inheritance. If you don’t see that, it’s because you don’t know much about GUI.” Then “Is it really required?” “Yes it is. Do you have any counterexample?” And on and on it goes.

          And while that may be an interesting theoretical discussion for those who want to write their own GUI toolkit, (but most people don’t, including those who are very loud in these debates) I can’t stop feeling all of these are kind of red herrings. The original formulation, “I don’t want to learn any programming language which lacks inheritance” is perfectly good and defensible position. Even if in the future someone writes a good GUI library without inheritance in Rust, people still may not want to learn a new way to do GUI. So whether it is possible to write a good GUI library without inheritance is not the main point of disagreement. It is there because it sounds better than the main disagreement.

          1. 2

            Interesting! This makes me wonder what alternatives there might be. In the toolkits I’ve used (mostly old Java stuff), objects are everything - style, layout, hierarchy, associated data, painting instructions, interaction handlers, and programmatic control flow. But a prominent counterexample is HTML + CSS + JavaScript - the hierarchy, layout, and default action handlers live in HTML, style lives largely in CSS, and program flow and non-default handlers live in JavaScript. You wouldn’t say that the “paint method” of a DIV does something. Instead, it’s more like you “apply” certain styles and behaviours to elements.

            Actually - duh - how does Servo do it? Is someone here able & willing to give a few sentence summary?

      2. 3

        … there’s currently an RFC going to make it (fields in traits) less silly. However, this has been going on at least since March 2016. Traits as a concept have been part of the language for numerous years. It’s currently September 2016. Why is such an important and vital part of the language missing, still?

        This is unreasonable expectation. I think people don’t realize how difficult and complex the language design is, and how long it takes.

        On the other hand, I think it is reasonable to ask “why isn’t fields in traits higher priority, or even the top priority?” And it is in fact not the top priority currently. So there is this combination of reasonable question of priority and unreasaonble expectation of language design speed.