On Sun, Mar 31, 2013 at 2:36 AM, Josh C. [email protected]
wrote:
The double vs single quotes doesn’t seem like a gotcha to me.
I was debating that one. The rule is the same in most languages that
HAVE string interpolation, so yeah, it shouldn’t be terribly
surprising. But in most languages I’ve used, one or the other (single
vs. double) is just plain invalid (for a multi-char string), or
they’re both equally valid, so there being a difference at all is a
bit of a gotcha.
The freezing one is good, but should be separated from the constants, as
it’s really just about variables. You can update the variable, but not
modify the object, so you have to know which you’re doing. Might also
mention that it is for just that one object, so freezing an array doesn’t
freeze the elements in the array.
Ah, yes, I had originally intended to do something about modding the
references vs. the object it points to. Forgot to split that out.
Array slots are of course simply a special case of that. I’ll split
'em out and work on it before the next time I present it.
Balanced whitespace is good (better example would be one -1
)
Oooh, good one!
The parent initialize one doesn’t seem legitimate to me, that’s how
inheritance works, why would you expect anything else?.
IIRC, in some languages, they do automagically run parental initters
for you by default. It’s been so long since I’ve done much OO other
than Ruby, especially with inheritance, that I forget which does what.
The example for local var in the block seems too contrived. It’s only ever
hit me when I tried to do something like .each{ |i| sum ||= 0; sum += i }
in the loop, in which case it always gets set to zero.
Well, yeah, they’re all rather contrived! I didn’t put a high
priority on thinking up a realistic example, so I’ll just swipe yours.

The idea credit seems out of place, the hash block setting the value has
been a common pattern for a long time.
I figured, better to give credit too much and take up extra space,
than to slight someone by stealing something. But to make you happy,
I won’t credit your loop/closure var-value-losing example. 
Frankly, I dislike it because it (a)
sets keys on access, regardless of whether or not they will be used (e.g.
you could be carrying around thousands of empty arrays),
Good point, I’ll add a caveat.
and (b) changes
behaviour of hash such that you must use #.has_key? to see if the key is
set, because otherwise, the key is always set.
True, but if you’re using it for a specific purpose, there’s probably
a more domain-relevant test. In the case I showed, someone wanting to
know if someone knows any computer languages might ask if
langs[employee].any?.
I think the
Array version of this is a better example,
Also useful… but I think it’s still worth pointing out this gotcha
with hashes too. I’ll make them separate slides, with Arrays first
since creating them all up front is clearer.
I’d maybe add lambda vs proc:
Yeah, I thought about delving into that, but it was a bit more
advanced than I wanted to inflict at that point. I was trying to keep
the whole talk under an hour, including Q&A, and the audience has a
wide range of skill levels. Maybe I’ll just save it for last, and
skip it if we’re running short of time, or their eyes are glazing
over…
Might also add method_missing, which is evil (I don’t think eval is evil,
but using method_missing on code that anyone else uses is sadistic)
Eh… if used judiciously, and correctly (including a super-call if
not figured out), it can be OK. And if someone is messing about with
method_missing, I think they’re probably experienced enough not to
need this presentation.
But now that you mention it, the need to
ALSO adjust responds_to_missing, is quite a gotcha.
Might also add floating point number imprecision.
That’s in pretty much any language, so I don’t really count that as
a Ruby gotcha per se.
Might also mention when a block gets instance evaled, but you’re calling
methods on your local context (e.g. a dsl you call from rspec can’t call a
let).
Now you’re just making my head hurt!
I think I read something on
that a few weeks ago, that I might be able to TL;DR-ify… or maybe it
was in the context of JavaScript, where issues of defining “this” are
critical AND common…
Might also add nonprinting characters,
Not Ruby-specific enough.
I’d also put the most relevant ones earlier, when people will be paying the
most attention.
Ordering is a bit of a tough question. I was initially trying to put
the easiest stuff first, so the Ruby-newbies could get some value out
of it before their eyes glazed over. 
Thanks,
Dave