2

As a Ruby programmer did you feel any time about any feature which is a bit risky to use, may be because of it's strange behaviour? It might be well documented but hard to find while debugging or counterintuitive to remember?

I generally try to stay away from String#gsub!. The doc says "Performs the substitutions of String#gsub in place, returning str, or nil if no substitutions were performed." So if there's nothing to substitute then it'll return nil. Practically I didn't see any use case where this comes handy.

SO, with your experience, is there anything else you'd like to add?

intellidiot
  • 11,108
  • 4
  • 34
  • 41
  • 3
    `gsub!` _won't_ overwrite the string value with `nil` if no substitutions performed. It will only _return_ `nil`. – Mladen Jablanović Apr 27 '11 at 18:21
  • 2
    `!?!` as an alternative for the `false` keyword ;) – Austin Taylor Apr 27 '11 at 18:25
  • `% space\ as\ a\ quote\ character ` – Austin Taylor Apr 27 '11 at 18:26
  • @Mladen Jablanović, yeah that's right. I've corrected the language. – intellidiot Apr 27 '11 at 18:27
  • You should *experiment* and find out if features are dangerous. That's what `irb` is for. – yfeldblum Apr 27 '11 at 18:30
  • @intellidot: Given the new information about `gsub!`, I don't see why you would avoid it. Which would you rather type? `str = str.gsub(..)` or `str.gsub!(..)`? – ryeguy Apr 27 '11 at 18:33
  • @ryeguy: Those two are *not* equivalent. In particular, the first one will *not* modify the original string. – Jörg W Mittag Apr 27 '11 at 18:42
  • I never said the methods were equivalent, but the 2 statements I provided are. The first one does modify the original string, because it's being assigned back to itself. – ryeguy Apr 27 '11 at 18:49
  • 1
    Define "risky" better. Nothing I've seen in Ruby scares me compared to burning the atmosphere off the planet, which was rumored to be a concern with the Manhattan project. It is highly unlikely you'll hurt anything with Ruby, unless you are programming something extremely sensitive, and, at that point you'll be very aware of the issues. If you're just learning I wouldn't worry about it. – the Tin Man Apr 27 '11 at 21:35

4 Answers4

2

Using return in a lambda, Proc or block. The semantics are well defined, but you will get it wrong, and you will get a LocalJumpError.

Community
  • 1
  • 1
Theo
  • 131,503
  • 21
  • 160
  • 205
  • How do you get a LocalJumpError by using a return from a lambda? – juan2raid Apr 27 '11 at 20:43
  • Should have been `Proc`, not `proc`. See it now? – Theo Apr 28 '11 at 05:29
  • I don't. I understand the dangers of using the return statement in a proc. But when you return from a lambda, it just returns from the lambda created proc and not the calling method. So what I don't understand is how to get a LocalJumpError when returning from a lambda. – juan2raid Apr 28 '11 at 16:22
  • My point is that it's easy to get it the wrong way around, and therefore it's a risky feature. Is `Proc.new { return 1 }` or was it `lambda { return 1 }`? The semantics are clearly defined, but if you're in a rush, are you sure you would always get it right? – Theo Apr 28 '11 at 18:26
1

The meta programming features of Ruby can be used in very dangerous ways. I've seen code that attempts to runtime-redefine common methods on code classes like String, or Array, and while I can see this being MAYBE acceptable for a tiny temporary script, I don't think it is remotely a good idea in a complex application with many dependancies, or many maintainers.

Chris Cherry
  • 28,118
  • 6
  • 68
  • 71
1

Well, the most widely abused dangerous feature of Ruby is certainly evaling strings. In vast majority of cases (if not all) it can be avoided using other methods, usually define_method, const_get, const_set etc.

Mladen Jablanović
  • 43,461
  • 10
  • 90
  • 113
1

throw/catch (not the same as begin/rescue!) is basically GOTO, and that could be considered to be a risky feature to use in any language.

Theo
  • 131,503
  • 21
  • 160
  • 205