Wisdom I picked up from Eloquent Ruby, Chapters 1-9 • Hacker News Board

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#11

Post by samstokes » Thu, Apr 05, 2012, 6:16 PM UTC

tferris wrote: post #2

I've just bought this book as well to get a deeper understanding of Rails (and also to get a newer book on Rails, most are aged). While the first chapters are a refreshing take on Rails and easy to understand the book is getting kind of cloudy later when covering more complex topics. Cumbersome explanations followed by wack examples give you a hard time—you cannot easily grasp basic ideas, so you constantly switch be…

Ruby's terminology is confusing here, but singleton methods have very little to do with the Singleton Pattern.

The Singleton Pattern is a way to design a class that ensures at runtime that only one instance of that class ever exists. Singleton methods are (effectively) methods defined on a particular object rather than being defined for all objects of a single class.

The terminology is actually correct, because the way singleton methods work is by generating an anonymous class to which only the object at hand belongs (thus that anonymous class is an example of the singleton pattern) and defining the method there, but if what you're interested in is how to define your own singleton classes then understanding singleton methods doesn't help you, and vice versa.

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#12

Post by riffraff » Thu, Apr 05, 2012, 7:53 PM UTC

this is not true:

    ||= expands to @variable = @variable || @other_variable

I am not sure if semantics of defined-or-assign operator changed in recent rubies, but ||= used to expand to

    foo or foo = bar.

Which is different in some edge cases, e.g.

    >> a= Hash.new(0)
    => {}
    >> a[:key] ||= :v
    => 0
    >> a
    => {}
    >> a[:key] =  a[:key] || :v
    => 0
    >> a
    => {:key=>0}

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#13

Post by rlander » Thu, Apr 05, 2012, 8:08 PM UTC

bstar77 wrote: post #3

Russ is one of the best technical writers I've read. I've only gotten through half of this book, but I've read his design patterns book cover to cover and it is fantastic. He recently did an appearance on Ruby Rogues for their book club episode on Eloquent Ruby: http://rubyrogues.com/033-rr-book-club-eloquent-ruby/ That's definitely a good primer if you on the fence about purchasing this book.

I agree.

I don't particularly care for Ruby nor OOP since I mostly use functional languages nowadays.

With that said, I read both books and they're among the best technical books I've ever read. Even I if never have to implement a pattern in Ruby in my life, the level of insight into the language is sky-high.

I just wish he would write Eloquent Clojure.

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#14

Post by bumeye » Thu, Apr 05, 2012, 9:25 PM UTC

danso wrote: post #7

>> Using a method that is called on self in a class, don’t use self.method_name when just plain method_name will do. (loc. 1500) I don't have the book in front of me so I don't know what the context is, but this strikes me as something as barely worth highlighting, other than to show that you grok Ruby's method chain. Some programmers would argue that using self.method_name helps clear up ambiguity to humans who read…

It fits in the Ruby philosophy and coding style to leave the `self.' out. But it might not be so evident for non-rubists.

Actually, new rubists might not even know that you can leave it out. In php you are required to use `$this->' for instance members.

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#15

Post by eaurouge » Thu, Apr 05, 2012, 10:22 PM UTC

danso wrote: post #7

>> Using a method that is called on self in a class, don’t use self.method_name when just plain method_name will do. (loc. 1500) I don't have the book in front of me so I don't know what the context is, but this strikes me as something as barely worth highlighting, other than to show that you grok Ruby's method chain. Some programmers would argue that using self.method_name helps clear up ambiguity to humans who read…

What's missing in the other comments is that you can't call private methods with an explicit receiver, for example my_object.private_meth or even self.private_meth. On the other hand, public and protected methods can be called on self.

See this blog post for more info: http://www.skorks.com/2010/04/ruby-access-control-are-privat...

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#16

Post by halostatue » Fri, Apr 06, 2012, 2:48 AM UTC

tptacek wrote: post #9

danso wrote: post #7

>> Using a method that is called on self in a class, don’t use self.method_name when just plain method_name will do. (loc. 1500) I don't have the book in front of me so I don't know what the context is, but this strikes me as something as barely worth highlighting, other than to show that you grok Ruby's method chain. Some programmers would argue that using self.method_name helps clear up ambiguity to humans who read…

Especially because some bare method calls will produce syntax errors ('class' being the obvious example). I think there's no good rule of thumb to be had here; use whichever style makes the code clearer.

That's exactly the rule of thumb that makes for good Ruby: use whatever style makes the code clearest. Over the last ten years, my Ruby has evolved as I've come to understand this (and it's affected the code I write in every other programming language I know, including bash scripts).

At times, this means I have to skip a one-liner because it's not as clear as expanding it out; at other times, it means using a one-liner because it's clearer than an expanded form. Sometimes it means using #length on a String or Array, sometimes it means using #size. They do the same thing (much to the annoyance of some folks), but the fact that both work means I can think about how my code reads.

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#17

Post by halostatue » Fri, Apr 06, 2012, 2:51 AM UTC

riffraff wrote: post #12

this is not true: ||= expands to @variable = @variable || @other_variable I am not sure if semantics of defined-or-assign operator changed in recent rubies, but ||= used to expand to foo or foo = bar. Which is different in some edge cases, e.g. >> a= Hash.new(0) => {} >> a[:key] ||= :v => 0 >> a => {} >> a[:key] = a[:key] || :v => 0 >> a => {:key=>0}

As far as I know, this behaviour is still the same; changing it would be a breaking change for those edge cases.

Re: Wisdom I picked up from Eloquent Ruby, Chapters 1-9

#18

Post by halostatue » Fri, Apr 06, 2012, 3:00 AM UTC

The suggested distinction elaborated on between {} and do/end blocks is…unfortunate.

The block types have different binding precedence, which affects their suitability for fluent (read as "DSL") interfaces. The reason that Rake tasks are defined as:

    task :foo do
      …
    end

and not

    task :foo { … }

is not just multi-line readability, it's because {} binds to :foo, but do/end binds to task.

Inasmuch as you want to make a different distinction between {} and do/end, Jim Weirich's suggested distinction is as good as any: use {} when you're going to be using the result of the block and do/end when you're not. Therefore:

    squared = (1..10).map { |i| i * i }
    (1..10).each do |i|
      puts i * i
    end

Yeah; I'll probably use {} for both because it's more readable in the simple case, but I find that I rarely use do/end when I'm using the value of the block, and I'll almost always use {}.