The hard part is doing without semicolons.

Perhaps I've been doing Ruby for too long, but it's still not that weird to me. The quantity "5" is very abstract without anything to have "5" of. That is why "5.days" and "5.times" exist, among others. Mathematically it makes just as much sense to start with the amount and add the unit later than it does to start with the unit and add the amount later (ie like `time_to_wait = SECONDS_IN_A_DAY * 5` as you might do in some other languages).

> that “times” is a property over the “5” object

Maybe here is the confusion, ruby is based on message passing, so the `times` is a message you are sending to 5, not a property of it.

When you're new it just looks like a weird-but-reasonable syntax.

When you learn the language you really fall into two camps:

- ah, yes, this is unusual, but it's consistent and now i understand the language

- this is way too clever

I'm more in the first camp.

In Smalltalk there is no if statement, but there is ifTrue and ifFalse methods in a Boolean variable. This is one example how to create custom control flow with non-local returns and blocks. Ruby follows suite.

Times isn’t a property of the 5 object, it is a method of the 5 object.

>Ruby has a concept of mixins (Golang interfaces), these are not objects.

Ruby "mixins" are the affordance of sharing instance methods from a module via a keyword. Modules are objects, and are instances of class Module:

  module ProvidesFooMixin
    def foo = "foo"
  end

  class Bar
    include ProvidesFooMixin
  end

  Bar.new.foo
  # => "foo"

  puts(ProvidesFooMixin.class)
  # => Module

  ProvidesFooMixin.object_id
  # => (some integer value)

Like all methods, `puts` is an object:

  method(:puts)
  # => #<Method: Object(Kernel)#puts(*)>

  method(:puts).class
  # => Method

  method(:puts).object_id
  # => (some integer value)

>What object does the method `puts` belong to?

It belongs to the object you are calling it from within. You don't need to call `puts` with a receiver because it is an instance method, just like you don't need to call an instance method `foo` via `self.foo`. But you could choose to use a receiver, since the `puts` you know and love is just another instance method. You can try `self.puts` for yourself in some context!

Your classes (and their instances) inherit this `self.puts` instance method from the Object class, which includes the Kernel module, which provides `Kernel#puts`. So the only reason you can send it as a message without a receiver is because it is just another instance method (again, the same as calling instance method `#foo` without using `self.foo`).

Caveat: You can build an "alternate universe" object hierarchy by inheriting from BasicObject, and in your alternate universe, you can choose to not `include Kernel`, and you will see that instances of your new objects do not have access to `puts` in their instance scope.

`puts` is just a method of the Kernel module: https://ruby-doc.org/3.4.1/Kernel.html#method-i-puts, just like `p` and many others. Kernel is included in the Object class that is the root of the class hierarchy, so its methods are available in every ruby object.

Mixins are just modules, which are objects, which you can call methods on. (Or rather, send messages to) You can easily verify this in irb calling a method on (for example) the Enumerable module:

    irb(main):001> Enumerable.class
    => Module

Well, “puts” is a method defined in the Kernel module, which is included in the Object class, which means it is available in all contexts (since every object is a subclass of the ‘Object’ class). So, to answer your question, the puts method belongs to the Kernel module object, and the Kernel module object is an instance of a Module object.

Answerable by a few minutes of googling. Sort of:

puts is a method which has a class: the Method class:

  irb(main):001:0> method(:puts)
  => #<Method: main.puts>
  irb(main):002:0> method(:puts).class
  => Method

  irb(main):003:0> 3.puts()
  Traceback (most recent call last):
          2: from /usr/bin/irb:11:in `<main>'
          1: from (irb):3
  NoMethodError (private method `puts' called for 3:Integer)

  irb(main):004:0> method(:puts).class.methods
  => [:allocate, :superclass, :<=>, :<=, :>=, :==, :===, :autoload?, :autoload, :included_modules, :include?, :name, :ancestors, :attr, :attr_reader, :attr_writer, :attr_accessor, :instance_methods, :public_instance_methods, :protected_instance_methods, :private_instance_methods, :constants, :const_get, :const_set, :const_defined?, :class_variables, :remove_class_variable, :class_variable_get, :class_variable_set, :class_variable_defined?, :public_constant, :freeze, :inspect, :deprecate_constant, :private_constant, :const_missing, :singleton_class?, :prepend, :class_exec, :module_eval, :class_eval, :include, :<, :>, :remove_method, :undef_method, :alias_method, :protected_method_defined?, :module_exec, :method_defined?, :public_method_defined?, :to_s, :public_class_method, :public_instance_method, :define_method, :private_method_defined?, :private_class_method, :instance_method, :instance_variable_set, :instance_variable_defined?, :remove_instance_variable, :instance_of?, :kind_of?, :is_a?, :tap, :instance_variable_get, :instance_variables, :method, :public_method, :singleton_method, :define_singleton_method, :public_send, :extend, :to_enum, :enum_for, :pp, :=~, :!~, :eql?, :respond_to?, :object_id, :send, :display, :nil?, :hash, :class, :singleton_class, :clone, :dup, :itself, :yield_self, :taint, :tainted?, :untrust, :untaint, :trust, :untrusted?, :methods, :frozen?, :protected_methods, :singleton_methods, :public_methods, :private_methods, :!, :equal?, :instance_eval, :instance_exec, :!=, :__send__, :__id__]

Modules (mixins) are objects, classes are also objects (of type Class).

The Kernel module is included in the Object class, which means its methods are available to every Ruby object and can be accessed from virtually any scope, including the top-level (global) context where self is an instance of Object called "main."

> I beg to differ. [...] Why do you not call puts with its objects name?

In the first place, I'd say what you're asking for goes beyond "everything is an object".

But I think your questions can be answered in a way that affirms that "everything is an object" in Ruby anyway.

> Why do you not call puts with its objects name?

Because it belongs to whatever object you're working in already; `puts` is identical to `self.puts`. And yes, you're always working in an object: https://bparanj.gitbooks.io/ruby-basics/content/chapter1.htm...

> What object does the method `puts` belong to?

As indicated above, it belongs to the object `self`. It gets added object via the mixing-in Kernel module into Object. Kernel is itself an instance of class Module: https://docs.ruby-lang.org/en/3.4/Module.html

The `puts` in Kernel delegates to `puts` from IO, which is likewise an instance method belonging to the object you can refer to by the name `$stdout`: https://docs.ruby-lang.org/en/3.4/IO.html

> Ruby has a concept of mixins [and], these are not objects.

Sure they are. Mixins themselves inherit from Module, and Modules are also objects (just like classes are).

Some highlights from Chapter 27 ("Library Reference: The Class Model") of the recent edition of the pickaxe book (emphasis mine):

> The Kernel module is included by class Object, so its methods are available in every Ruby object. One of the reasons for the Kernel module is to allow methods like `puts` and `gets` to be available everywhere and even to look like global commands. Kernel methods allow Ruby to still maintain an "everything is an object semantics".

and regarding mixins:

> The Module class is the class of any module you declare with the `module` keyword. Each module is an instance of class Module.

on Object:

> Object is the parent class of (almost) all classes in Ruby unless a class explicitly inherits from. BasicObject. [...] Object mixes in the Kernel module, making the built-in functions globally accessible.

tl;dr: mixins in Ruby are instances of class Module, and their methods end up bound to instances of class Object. Abstract module methods that don't belong to a concrete instance of some class that mixed in their module belong to the Object that is the module itself (the instance of class Module). (The same kind of thing is how class methods work.)

you can view it as serving the same role as universal function call syntax, the latter being a feature in some other languages that rewrites `a.f(x)` to `f(a, x)` if `a` doesn't have a method `f`. in ruby you can just add the method to `a`'s class directly, but the idea is the same - you're adding some user defined function that is closely related to the type of `a`, and you're using method call syntax because that reads nicely.

Maybe I explained it a bit imprecise. I was trying to explain the following behavior:

    def foo
      p 1
      yield
      p 2
    end

    foo { break }

#if and #ifTrue are yours if you want them:

  class TrueClass
    def if = true
    def ifTrue = true
  end

  class FalseClass
    def if = false
    def ifTrue = false
  end

  true.if
  # => true
  false.if
  # => false

basically it's because of "else" and "elsif". While ".each" works the same as "for .. in ...; end", it's harder to do "if else" as method which will also return value of the block inside the branch. Smalltalk can do it because "ifTrue:ifFalse:" is _one_ message, ruby didn't go that way syntactically.

> In your experience, is it ok to use Procs for example for extraction of block methods for cleanliness in refactors?

In addition to the efficiency issues of unnecessarily reifying blocks into Proc objects, there are some sharp edges that can cut you doing this. For instance, Ruby blocks and procs [0] have return semantics based on where they are defined (specifically, "return" in a block or proc returns from the method in which the block/proc is defined.) So if you have two identical blocks used in two different methods, and those blocks have return calls, and you refactor them to shared Proc defined somewhere else that is used in each method, you will find that the behavior is broken, and when it returns it will either return from the wrong method or produce a LocalJumpError, depending on the exact structure of the program.

Local return from a block/proc is done with "next" instead of "return" (and if neither a next or return is hit, the last expression evaluated will be treated as an implicit "next"), so a block without an explicit return can be converted to a proc and reused in different places more safely.

[0] using the convention of lowercase "proc" to refer to a Proc object that does not have lambda semantics, whereas those created with Kernel#lambdda or the stabby-lambda syntax are "lambdas".

You shouldn't have much difficulty, Ruby converts blocks to Procs whenever it needs an actual object. Their semantics are intentionally kept the same. This is unlike lambdas, whose semantics are closer to methods.

Pass the wrong number of of arguments to a Proc or block, it will pass nil for missing args and omit extras. Pass the wrong number of arguments for a method or lambda and you get an ArgumentError. Use the return keyword in a lambda, it returns from the lambda, just like if you call return in a method. In a block or Proc, it returns from the calling method.

So I would feel comfortable leaning on them for refactoring as it's as Ruby intended. Just use lambdas when you want to turn methods into objects and Procs when you want to objectify blocks.

You should get ahold of a copy of Metaprogramming Ruby 2 if you find yourself refactoring a lot of Ruby. It's out of print, but ebooks are available.

This sounds like a really innovative idea. I haven't seen a dedicated place for "collection of useful procs", but one emerging pattern is to use `app/services` and then have a bunch of single-responsibility service classes that each have call or perform method and then you use the service when you need some shared functionality. It's like a proc, but instead it's a class with `#call` method.

Sorry for the late reply. Some others have responded and I mostly agree, but I will add where I can.

>is it ok to use Procs for example for extraction of block methods for cleanliness in refactors?

As others have said, use Lambdas via `->() { do_thing }` over Procs if you want to pass them around. They are the "true" way to use first-class functions.

Also, if you want to pass methods around, you can do so, just be aware that they carry everything you might expect with them: they are called with the receiver still being the object they came from. Callbacks are uncommon in Ruby, but I've seen a few instances of passing methods of the current object into some other as a callback, e.g.

  some_interactor.do_complex_thing(
    order_id: 123, 
    on_success: method(:succeeded),
    on_failure: method(:failed),
  )

>Also, is there any particular Rails convention to place collections of useful procs?

No convention for a "place" for these. I generally dislike how Rails got people into using directory names for the "kind" of a module/class instead of actually mirroring the architecture. This is kind of why.

If what you really desire is a big bag of pure functions in the global scope, you should still at least put them inside of a namespace (a Ruby module). For example, if you wanted a big bag of type coercions, you might put them into a module:

  module CommonCoercions
    class << self
      def currency
        ->(value) { do_things }
      end

      def coordinates
        ->(value) { do_things }
      end
    end
  end

  module CommonCoercions
    class << self
      def currency
        @currency ||= ->(value) { do_things }
      end

      def coordinates
        @coordinates ||= ->(value) { do_things }
      end
    end
  end

  module CommonCoercions
    class << self
      def currency(value)
        do_things
      end

      def coordinates(value)
        do_things
      end
    end
  end

  CommonCoercions.method(:currency)

However, if you want to use them only locally within a particular class, in a Rails project you are better off just calling them directly on the module, or even delegating so that the method is available in the class as though it were a local instance method:

  module CommonCoercions
    def self.coerce_currency(value)
      do_things
    end
  end

  class SomeAction
    delegate :coerce_currency, to: CommonCoercions

    def some_method(params)
      coerce_currency(params.fetch(:amount))
    end
  end

As much as I love Ruby (and I love it a lot - I right now have Claude fix eigenclass compilation issues in another window in my long-languishing Ruby compiler hobby project), this is also the root of a lot of confusion.

Ruby has two types of closures: lambda's, where return returns to the caller, and proc's/blocks where return acts as a return in the defining scope.

Beginners often struggle with the distinction between lambda and block, and often will be wildly confused if they ever see "proc" in the wild.

Yet lambda and proc both return a Proc object, and if you take the value of a block, you also get a Proc object... Just with different return semantics...

It'd be nice if this was a bit clearer.

Yes, that is why that behaviour is known as closures.

Also why in languages like C++, you get to control what is captured from the calling context.

I've used Sorbet a lot but don't really count it. I understand why others would but I find the type system is extremely shallow and limited and the overhead it adds to development (and even performance) is substantial.

Also Ruby has RBS now which is not inline and... much maligned to say the least. I think the entire ecosystem is at a crossroads rn wrt typed Ruby

And also RBS-inline if you want Jsdoc style typing

It's a closure. The lisp equivalent is also a closure, and the JS equivalent is a function (which is a closure as they can refer to variables in the scope they're defined in. To test this define a function inside a function and reference variables defined in the outer function, and return the inner function).

That's what I'm saying: In Ruby, you can transplant code from a closure out of its lexical scope and evaluate it as if it was defined in a different environment.

Should you ever do this? No. But you can. :-)