31–40 of 59 posts
Earlier quoted context omitted.
Would you prefer a *rest argument? An options hash is the best way to make your ruby API flexible.
Plain old objects are the best way to make your API design flexible. You can't easily change the behavior of setting a key/value pair for an individual hash. Objects are designed to implement behavior, Hashs are meant to hold key value pairs.
Earlier quoted context omitted.
used it to bolster you're own "Top 100 rails" status. I've mostly stopped using Rails and Ruby in favor of Io, so I have no interest in bolstering my Rails status. I was just providing evidence to counter your assertion that I was a Ruby newb. The notion that you can follow singular design principles in all situations is absurd, if you ask me. I agree that "it depends", but using Hashes as arguments has become idioma…
I wasn't assuming you were a newb, just that you didn't have much exposure to what are commonly regarded as well designed Ruby libraries. It didn't occur to me that you'd have had that exposure and yet sound as if you were shocked and appalled about what is common practice. I still would really like to see examples of well designed open source Ruby projects that follow what you consider to be decent design principles…
Earlier quoted context omitted.
I wasn't assuming you were a newb, just that you didn't have much exposure to what are commonly regarded as well designed Ruby libraries. It didn't occur to me that you'd have had that exposure and yet sound as if you were shocked and appalled about what is common practice. I still would really like to see examples of well designed open source Ruby projects that follow what you consider to be decent design principles…
Which libraries do you consider well designed? I'll let you know how I think that they could be improved.
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.
Earlier quoted context omitted.
Which libraries do you consider well designed? I'll let you know how I think that they could be improved.
I've already written an entire book on this and given it away for free. I suggest you read it and write a review. Be specific, and show good counterexamples. I'll be happy to link you when you do. 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'…
#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))Earlier quoted context omitted.
Would you prefer a *rest argument? An options hash is the best way to make your ruby API flexible.
Plain old objects are the best way to make your API design flexible. You can't easily change the behavior of setting a key/value pair for an individual hash. Objects are designed to implement behavior, Hashs are meant to hold key value pairs.
Remember you don't need to destructure the hash. You've got a local one initialized to sensible defaults, and you .merge! it with the param one, and then just use the hash values as your local vars.
https://docs.google.com/fileview?id=0B8mB_WI1jRkCMzgyZWY5MzY...
Earlier quoted context omitted.
Plain old objects are the best way to make your API design flexible. You can't easily change the behavior of setting a key/value pair for an individual hash. Objects are designed to implement behavior, Hashs are meant to hold key value pairs.
Right, the keys/values need to have supporting logic. And yeah if you're sticking procs in a hash, just use an object; but if your object is just a bunch of fields, use a hash. And often that's all you need. I just want to override the marginWidth on this fooBar. Remember you don't need to destructure the hash. You've got a local one initialized to sensible defaults, and you .merge! it with the param one, and then ju…
I think the central issue is that there is too much friction to creating new classes in Ruby. It feels official and final. In Io, you just clone an existing object like you would send any other message.
Here's a copy on Google Docs. I hate PDFs: https://docs.google.com/fileview?id=0B8mB_WI1jRkCMzgyZWY5MzY...
Looks like it loses some quality on translation to Google docs, though...
Earlier quoted context omitted.
I've already written an entire book on this and given it away for free. I suggest you read it and write a review. Be specific, and show good counterexamples. I'll be happy to link you when you do. 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'…
#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 int…
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.