> When I write ruby code, I keep wondering "where does this method come from?" and have to grep my codebase.
Sounds like a shortcoming of your tools. I spend a lot of time in Visual Studio working on native C++ and even there I can ctrl-click on something and jump to the declaration or definition. I bet there's something even better for Ruby.
Yeah probably, I don't use any IDE feature for ruby code. It's still a problem that all methods available in current scope are not immediately obvious, though. And if you try to inspect available methods on an object in a REPL console using `#methods`, there usually are hundredth of them, especially when using rails (although to be fair, it's not all due to inheritance, there are also a lot coming for mixins). I suppose ruby IDEs have the same problem.
When I write go code, I have a lot of static analysis tools, but I'm still glad it's easy for me to know what I can call without stopping for inspection.
Unfortunately jumping to definitions in Ruby is often hit-or-miss since the language is very dynamic and idiomatic Ruby code often uses a fair amount of metaprogramming.
Even Sublime text can jump to definition for most languages, and it's no IDE.
Re:G.E.R.T: Golang Embedded Run-Time
by jbarciauskas on Tuesday October 31, 2017 @08:53AM
(#15592817)
Pattern matching interfaces also makes finding exactly what underlying object is being used in a given context difficult as well. With explicitly declared interfaces, you can easily find all implementations. With pattern matching it's a bit more complicated.
Yeah indeed, there's that too, although I'm glad we can't define methods on interfaces (using the interface as method receiver), so it quite reduces the complexity to just having to figure out the actual type, most often found just by inspecting the caller.
"Composition over inheritance" is not a new trend, that was actually mentioned in first chapter of Gang of four's Design Patterns in 1995 [1]. In that regard, I feel like we mostly failed to ever use OOP properly (although, "fail" is probably too strong a word).
I'm actually annoyed that embedded types exist in go because it re-introduces the same problem (but I have an easy fix for that: I don't use them).
But really, what you're describing is a data structure problem. This can be solved without OOP, and structs are especially good at it.
[1] https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2...