News for hackers. Stuff that matters.
Re:Rails is not written in Ruby by drusepth on Friday February 04, 2022 @07:41PM (#30215718)
The former's inherent namespacing is exactly why I prefer it. You know exactly where each method came from (it's a method that exists in a `some_array` instance namespace); inversely, I have no idea where `has_my_thing(foo)` comes from or what all it can be used for if it's just sitting in the global namespace.

Very often, when I'm learning new code, there's one line I'll write over an over in console bindings:

    > some_object.methods
It provides a super-easy way to learn what methods are actually relevant to `some_object` without having to pour over every method available in the global namespace and figure out whether `some_object` is a valid argument to each. You can also apply set logic like `some_object.methods - {}.methods` to return only the methods available on `some_object` that AREN'T on typical objects, which is a very, very, very powerful learning/exploration tool.

For example,

    irb(main):003:0> PaypalService.methods - Service.methods
    => [:create_prepay_invoice, :build_client, :capture_invoice_funds, :get_order_info, :get_plan_price]
Side note: you can also call `.source_location` on any method to see exactly what file/line it's defined in (even in core ruby/rails methods). There's a lot of other inspection methods available to learn more about objects and what you can do with them, which IMO is a benefit over your latter example.
Re:Rails is not written in Ruby by nitrogen on Friday February 04, 2022 @09:40PM (#30216527)
Along these lines, I recommend also trying Pry's ls command, which breaks the methods down by which module or class implements them for a given object, and the show-source command.

It's this great ease of introspection that makes Ruby so fun.