51–59 of 59 posts
Earlier quoted context omitted.
With the hash args the order could vary so I had to keep looking up what the possible argument key values could be. You can set slots on objects in any order that you want to: Foo.new.set_x(x).set_z(z) ...
That is insanely ugly. I will pass, thanks.
It would seem you only see the surface beauty of things. [redacted -- good point]
Earlier quoted context omitted.
That is insanely ugly. I will pass, thanks.
Setters are composable and you can modify their behavior. Hash literals ... not so much. It would seem you only see the surface beauty of things. [redacted -- good point]
Is that how you defend an API? Insult the user?
Holy shit that's stupid.
Earlier quoted context omitted.
#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…
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 t…
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.
Earlier quoted context omitted.
Hey Gregory, thanks a lot for sharing your experience and of course for the book itself. I'm just beginning to write an R graphs cookbook. Do you have any tips for a first time author?
Like most authors, I'll encourage you to think about not doing it, first :) If you're just looking to get your ideas across, you'll almost certainly get more mileage out of writing articles, doing talks, etc. And if you're looking to make money, unless you get very lucky, you won't make it directly off your book. It will almost certainly lead you towards other opportunities, but really all it creates is potential, th…
Earlier quoted context omitted.
Hey Gregory, thanks a lot for sharing your experience and of course for the book itself. I'm just beginning to write an R graphs cookbook. Do you have any tips for a first time author?
Like most authors, I'll encourage you to think about not doing it, first :) If you're just looking to get your ideas across, you'll almost certainly get more mileage out of writing articles, doing talks, etc. And if you're looking to make money, unless you get very lucky, you won't make it directly off your book. It will almost certainly lead you towards other opportunities, but really all it creates is potential, th…
Earlier quoted context omitted.
Like most authors, I'll encourage you to think about not doing it, first :) If you're just looking to get your ideas across, you'll almost certainly get more mileage out of writing articles, doing talks, etc. And if you're looking to make money, unless you get very lucky, you won't make it directly off your book. It will almost certainly lead you towards other opportunities, but really all it creates is potential, th…
Wow! I'm glad I came back into this thread -- these are all such great tips. Especially the advisory group (item 2)
When I was co-authoring Pro VB 6 & XML I was always coming across topics that could be books in themselves. Database details, designing COM objects, stuff like that.
I hated the idea that a chapter would leave the reader n limbo over some key aspect, but also didn't want to book to be even larger than it was likely to be, and explaining stuff can get hard.
So there were lots of places where I simply had to point and refer the reader to some other book or resource. There's not much you can do about that other than try to be mindful of when it is the right choice.
Earlier quoted context omitted.
Wow! I'm glad I came back into this thread -- these are all such great tips. Especially the advisory group (item 2)
The point about leaving stuff out is very important. When I was co-authoring Pro VB 6 & XML I was always coming across topics that could be books in themselves. Database details, designing COM objects, stuff like that. I hated the idea that a chapter would leave the reader n limbo over some key aspect, but also didn't want to book to be even larger than it was likely to be, and explaining stuff can get hard . So ther…
Anyway, point being, I was pretty obsessive about not letting the book balloon. It forced me to put the knife to a lot of good content that wasn't quite great.
Earlier quoted context omitted.
The point about leaving stuff out is very important. When I was co-authoring Pro VB 6 & XML I was always coming across topics that could be books in themselves. Database details, designing COM objects, stuff like that. I hated the idea that a chapter would leave the reader n limbo over some key aspect, but also didn't want to book to be even larger than it was likely to be, and explaining stuff can get hard . So ther…
I decided ahead of time that my book would be exactly 300 pages. I submitted an exactly 300 page manuscript, but I think my copyeditor shaved two pages of extraneous words :-/ Anyway, point being, I was pretty obsessive about not letting the book balloon. It forced me to put the knife to a lot of good content that wasn't quite great.
Earlier quoted context omitted.
That is insanely ugly. I will pass, thanks.
Setters are composable and you can modify their behavior. Hash literals ... not so much. It would seem you only see the surface beauty of things. [redacted -- good point]
def to_hash
{:x => @x, :y => @y}
end
def to_ary
[@x,@y]
end
def [] i
case i
when 0,:x
@x
when 1,:y
@y
end
end