views:

147

answers:

3

I'm just starting with Ruby and I personally find the following to be a violation of the "principle of least surprise". And that is, quoting from the documentation, that uniq! "removes duplicate elements from self. Returns nil if no changes are made (that is, no duplicates are found)."

Can anybody explain this, which seems completely counter-intuitive to me? This means that rather than be able to write one line of code below by appending .uniq! to end the first line, I instead have to write the following two lines:

  hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/)
  hooks = hooks.uniq

Or am I missing something, a better way?

EDIT:

I understand that uniq! modifies its operand. Here's the problem illustrated better I hope:

  hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/)
  puts hooks.length #50
  puts hooks.uniq!.length #undefined method `length' for nil:NilClass

I contend that the way uniq! works makes it completely senseless and useless. Sure in my case as pointed out I could just append .uniq to the first line. However later in the same program I am pushing elements onto another array inside of a loop. Then, under the loop, I'd like to "de-dupe" the array, but I dare not write 'hooks_tested.uniq!' because it could return nil; instead I must write hooks_tested = hooks_tested.uniq

Indeed I contend this is a particularly egregious mis-feature in that it is a well known principle that, when devising a method that returns an array, one should always at least return an empty array, rather than nil

+2  A: 

You can append uniq (no exclamation mark at the end) to the end of the first line.

Or, if you insist on using uniq!, use

(hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/)).uniq!
Mladen Jablanović
yeah i guess i can in this case
George Jempty
+4  A: 

The exclamation point on uniq! indicates that it modifies the array instead of returning a new one. You should do this:

hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/).uniq

or this

hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/)
hooks.uniq!
puts hooks.length
mckeed
Typically, if you use the bang-form of a method it will be the only method acting on that particular object (i.e., not in a chain). This is in part to eliminate ambiguous statements such as `hooks = hooks.uniq!.sort` or `hooks.uniq!.sort!` (where you can have what amounts to multiple assignments to the same variable in the same expression) or assignments to intermediate, temporary values such as `hooks.uniq.sort!`. `Array.uniq!` also returns `nil` instead of `[]` so you can do things like `if (hooks.uniq!)` to modify the array and perform a special action if anything was changed.
bta
You're second suggestion results in "undefined method `length' for nil:NilClass" if it hooks contains no duplicates -- this is precisely the unexpected behavior I am trying to draw attention to, but apparently it is falling on illogical -- er, deaf -- ears
George Jempty
Okay, sorry. If the second example doesn't work, there is something else going on here. What version of Ruby are you using?
mckeed
+2  A: 

This is because uniq! modifies self and if uniq! would return a value you wouldn't be able to know whether a change actually occurred in the original object.

var = %w(green green yellow)
if var.uniq!
  # the array contained duplicate entries
else
  # nothing changed
end

In your code you can simply write

hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/)
hooks.uniq!
# here hooks is already changed

If you need to return the value of hook perhaps because it's the last method statement just do

def method
  hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/)
  hooks.uniq
end

or otherwise

def method
  hooks = IO.read(wt_hooks_impl_file).scan(/wt_rt_00\w{2}/)
  hooks.uniq!
  hooks
end
Simone Carletti
The return values from "exclamation" methods are often arbitrary like this because they modify the object in-place. What's unfortunate about this case is some of the semantical mess it creates, as illustrated by your example: if uniq! then...actually not unique.
tadman