5 ms·

>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of

• dbaupp 9y ago
  Having aggregate data types and syntactically having methods seems like a very facile definition of "OOP", versus the conventional uses referring to Smalltalk style message passing or inheritance and overrides. Other than being able to call functions as x.foo() rather than foo(x) or foo x or similar, languages like Haskell and C seem to satisfy the requirements for being OOP, which seems to make "OOP" completely useless as a category. In any case, this point is been argued at length for every language, including Rust.
  • sanxiyn 9y ago
    I actually think having syntactic methods is an important (if not the most important) part of "OOP". You compared x.foo() with foo(x), but that's the wrong comparison. The correct comparison is that when x if of type Tree, x.foo() vs tree_foo(x). Otherwise you get name clashes. That is, I think the essence of "OOP", OOP-as-used, not any theoretical OOP, is function name resolution depending on type. That and syntax. So first, you write x.tree_foo() instead of tree_foo(x) which is purely syntactic. And then you shorten x.tree_foo() to x.foo(), because x is a tree, which is a great semantic help. According to this definition, Haskell and C are not "OOP", which matches common understanding.
    • dbaupp 9y ago
      That's a great point and one I hadn't considered, thanks!
    • pdpi 9y ago
      Function name resolution isn't OOP, it's attaching a namespace to a type. The _really_ important part is dynamic dispatch. You can have proper OOP without method syntax, it just looks awkward to our eyes. In fact, in Objective C, [obj doStuff: foo withBar: bar] gets desugared into objc_msgSend(obj, NSSelectorFromString(@“doStuff:withBar:”), foo, bar)
      • sanxiyn 9y ago
        I already agreed function name resolution isn't OOP. My argument was that it is "OOP", with quotes. My supporting evidence is that people consider C++ without any dynamic dispatch as "OOP", with quotes.
• vvanders 9y ago
  Rust doesn't have inheritance which is one of the key pieces of OOP. Traits just provide a single level of indirection and if you want to do anything more complex you'll need to use composition to achieve it.
• deleted 9y ago
  [deleted]
• kccqzy 9y ago
  By that definition, Haskell is an OOP language too, because Haskell has type classes (traits/interfaces) too, and you can have associated methods/associated types too.
• leshow 9y ago
  It's not though, AFAIK the x.foo() syntax is just sugar for let a = Foo; Foo::bar(&a); // if bar takes &self Plus, there is no concept of inheritance. I don't see how that meets any definition of OOP unless you make the definition so weak as to be meaningless.
• saghm 9y ago
  Depending on the language, interfaces can be a lot less powerful than traits. Traits can have default implementations for some methods (meaning you don't have to explicitly implement all of them), and in some cases they can be completely derived automatically. They're really more similar to Haskell's typeclasses than traditionally OO interfaces.
• mikebenfield 9y ago
  > What? If you have instantiatable abstract data types with associated methods you have a "class". Calling them "structs" does not change that. There are classes defined with "struct" in C++ and D too. So if I just take C's structs and add the ability to associate structs with functions using a "struct.function" notation, I now have classes? If so, a class isn't a very powerful concept, is it? Here's an easy way to see the difference between traits and interfaces, and simultaneously see why some people find OOP completely inadequate for their purposes. Imagine you're implementing several different types that all need to be able to be added. You've got integers, floats, mathematical vectors, and possibly other types. All of them should support an `add` method. But you should only be able add objects of the same type: an integer to an integer, a float to a float, and a vector to a vector. This incredibly simple idea, to my mind almost the simplest thing a person might want to do with a type system, cannot be expressed in most OOP languages using an interface with an `add` method. But it can easily be expressed using traits (or using Haskell's type classes). And this is why I never understood why anyone bothers with OOP.
  • everheardofc 9y ago
    Because nobody bothers with "OOP" or "FP" because there is not a single cannonical implementation of these that everyone agrees on. What you're talking about has nothing to do with neither. Any language that has generics can have self types or whatever you want to call them. It's a matter of whether the language has a strong static typesystem and most FP-style languages have these and a minority of OOP-style languages has them too. The reason why I use C++ has nothing to do with a preference for OOP. It's because all the widely used alternatives have terrible performance. I hate dealing with C++ projects. I hate dealing with memory leaks and segfaults. But that doesn't stop me from creating more of them and working on existing ones. All of that because the resulting memory footprint and performance are worth it.
    • mikebenfield 9y ago
      You seem to be trying to argue with me, but the points you're making are pretty much orthogonal to the ones I made. If you think OOP is not a meaningful concept, you should be arguing with the comment I was replying to, not me.
• pdpi 9y ago
  > Oh and calling an interface a "trait" does not change its fundamental nature either. Traits are a form of ad hoc polymorphism and behave closer to Haskell's typeclasses than they do to interfaces and subtype polymorphism.