On Mon, Oct 8, 2012 at 5:22 PM, Joe Groff <[email protected]> wrote: > On Mon, Oct 8, 2012 at 3:19 PM, Eddy Cizeron <[email protected]> wrote: >> Sorry I have not made myself clear enough. My point is absolulety not say >> that inheritance is a good/bad/required/unnecessary feature. My point is >> that if you're not using it (or at least if you're not using dynamic >> linkage), I cannot see where or why OOP concepts and syntax are relevant >> anymore. (But apparently there are some attempts to use dynamic linkage with >> interfaces and I didn't know that). > > One minor non-semantic, non-scientific benefit of OOP syntax over > Algol-style function application syntax is that it's syntactically > more composable—compare `a.foo().bar().bas()`, which reads > left-to-right and composes to the right, to `bas(bar(foo(a)))`, which > reads inside-out and requires bracketing on both sides of an inner > experssion to compose calls. (Of course this only works if your APIs > are designed up front in a "fluent" way, and isn't quite as flexible > as what you can do with combinators in ML or Haskell.)
I think there are two other benefits. The first is intellisense/code completion. Type "foo." and get a list of all methods in scope with a matching self type. This can be a massive productivity boost as it basically puts all your code and documentation in the IDE in a context sensitive way. Much harder to do this if you have to remember the name of the method before you see anything. Second, and much more subjectively, I think there's a difference between sort of value oriented programming, and the more low level mutable programming type where you're dealing with "objects" that have identity and complicated invariants. Subjective, but tying the methods to the data type in those cases "feels" okay to me because they kinda are inseparable in practice, so they might as well be syntactically tied together as well (with a more functional style you would group them by modules and visibility, but syntactically it doesn't look like an indivisible "object" that have a small set hard-wired built in methods on it as opposed to a value and a random grab bag of operations that happen to have matching types but could be written by any old schmuck and not necessarily "part of the object"). -- Sebastian Sylvan _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
