Until then, stop acting like you're some sort of authority (NOTE: This is not to claim I am -- because I'm not and no one is.) I just think it'd make sense to put your ideas into a bit of context so people can see that you're not just being critical for the sake of being critical.
#from your book
def distance(*points)
case(points.length)
when 2
x1,y1,x2,y2 = points.flatten
when 4
x1,y1,x2,y2 = points
else
raise ArgumentError, "Points may be specified as [x1,y1], [x2,y2] or x1,y1,x2,y2"
end
Math.hypot(x2 - x1, y2 - y1)
end
puts distance(1, 2, 5, 6)
puts distance([1, 2], [5, 6])
# why would you choose to make a complicated interface that requires a complicated implementation?
# simple, clear interfaces that allow for simple implementations
# are almost always preferrable to complicated ones that save a
# keystrokes through syntax
class Point
attr_accessor :x
attr_accessor :y
def initialize
self.x = 0
self.y = 0
end
def self.with(x, y)
new.set(x, y)
end
def set(x, y)
self.x = x
self.y = y
self
end
def distance_to(a_point)
Math.hypot(a_point.x - x, a_point.y - y)
end
end
puts Point.with(1, 2).distance_to(Point.with(5, 6))Point.with(1, 2).distance_to(Point.with(5, 6))
Over this?
distance [1,2], [5,6]
I guess it depends on how many interesting things you wanted to do with points. As things get more complicated, maybe something like this is worthwhile, but I don't feel that making everything an explicit object is categorically better.
But the section you're quoting is among the most contrived examples that RBP gives, it's mainly just part of a list of the different sorts of argument processing Ruby offers and the trade-offs betweeen them.
Maybe you skimmed and missed that, or maybe you read through and chose to ignore that detail.