3 ms·

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

by sandal 17y ago

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. I think that'd make a much stronger case for your argument, and might open my eyes to something that's been in a blind spot. Personally, I feel like a certain amount of API design is bound to what consumers will expect. We can certainly stretch and shift their tendencies, but if we fly in the face of them, our perfection in a vacuum will never be appreciated.

richcollins 17y ago
Which libraries do you consider well designed? I'll let you know how I think that they could be improved.
- sandal 17y ago
  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're not just being critical for the sake of being critical.
  - richcollins 17y ago
    #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))
    - sandal 17y ago
      So you mean that you prefer this: 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.
      - stevedekorte 17y ago
        The problems I have with "distance [1,2], [5,6]" are: 0. It breaks the fundamental OO convention and doesn't encapsulate logic and data. 1. It's not clear what it means unless you look up the docs. 2. It's implementation is complex, making it more difficult to understand and maintain 3. It fails to separate concerns, making it less extensible/modifiable. e.g. What if you wanted to override the setting behavior? You couldn't do it in one place.

by sandal 17y ago

richcollins 17y ago

Which libraries do you consider well designed? I'll let you know how I think that they could be improved.

sandal 17y ago
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're not just being critical for the sake of being critical.
- richcollins 17y ago
  #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))
  - sandal 17y ago
    So you mean that you prefer this: 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.
    - stevedekorte 17y ago
      The problems I have with "distance [1,2], [5,6]" are: 0. It breaks the fundamental OO convention and doesn't encapsulate logic and data. 1. It's not clear what it means unless you look up the docs. 2. It's implementation is complex, making it more difficult to understand and maintain 3. It fails to separate concerns, making it less extensible/modifiable. e.g. What if you wanted to override the setting behavior? You couldn't do it in one place.