Hacker News new | ask | show | jobs
by capableweb 1951 days ago
> In that context, what does it mean to be "first class"

It's easy. First, what does it mean to be "first class"?

> a first-class citizen (also type, object, entity, or value) in a given programming language is an entity which supports all the operations generally available to other entities. These operations typically include being passed as an argument, returned from a function, modified, and assigned to a variable

Secondly, how does that apply to functions?

> [First class functions] means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures

In what way doesn't Ruby have first class functions? This article explains it better: https://codequizzes.wordpress.com/2014/05/19/ruby-methods-ar...

In practice, because of Proc, you can use Proc wherever you'd use functions and get the same effect in practice, so this is not a big issue. But just because Ruby has Procs, doesn't mean it has first class functions, which is a specific concept.

2 comments

Thanks, I had also looked for a definition. Instances of Method fulfill both of the cited criteria -- example in this thread, above. Also: Method != Proc, but the article's comments help.

I, aha, notice this:

    $ irb
    2.3.3 :001 > Kernel.method(:puts).object_id
     => 47165335040720 
    2.3.3 :002 > Kernel.method(:puts).object_id
     => 47165334993360 # not the same!
    2.3.3 :003 > 
That is: #method doesn't return the Kernel.puts method, it returns a new Kernel.puts Method instance on each invocation. So the returned object from Kernel#method isn't the "real" (first-class) method object.

I feel like I'm a lot closer but I'd still like a better definition :)

Isn't the main issue that Ruby simply doesn't have functions? Ruby is pure OOP, and there is no way to define a method without the implicit 'self' argument. Maybe the reasoning was that methods themselves aren't really meant to be passed around. Because in today's idiomatic Ruby, they mostly aren't -- the late binding behavior of 'send' feels much more Rubyish.
Exactly. And Ruby methods are not even "functions with self" they are message-handlers. Like in Smalltalk or Objective-C.

Different heritage