Bug #3016
closedEnumerable#slice_before and dup
Description
=begin
When writing the specs for slice_before, I was surprised that it doesn't call #dup.
class X
def dup
raise "Hi!"
end
end
[:foo].slice_before(X.new){}.to_a
==> [[:foo]], I expected it to raise¶
The implementation calls directly rb_obj_dup.
It's a minor issue, but would it not be best to call dup on the argument? Most special needs for #dup can be addressed by initialize_dup, but maybe there are some reasonable cases where some user classes will redefine #dup?
The same question is valid for Enumerable#chunk.
diff --git a/enum.c b/enum.c
index b69d8c9..e6e6adb 100644
--- a/enum.c
+++ b/enum.c
@@ -14,7 +14,7 @@
#include "node.h"
VALUE rb_mEnumerable;
-static ID id_each, id_eqq, id_cmp, id_next, id_size;
+static ID id_each, id_eqq, id_cmp, id_next, id_size, id_dup;
static VALUE
enum_values_pack(int argc, VALUE *argv)
@@ -2189,7 +2189,7 @@ chunk_i(VALUE yielder, VALUE enumerator, int argc, VALUE *argv)
arg.yielder = yielder;
if (!NIL_P(arg.state))
-
arg.state = rb_obj_dup(arg.state);
-
arg.state = rb_funcall(arg.state, id_dup, 0, 0);
rb_block_call(enumerable, id_each, 0, 0, chunk_ii, (VALUE)&arg);
if (!NIL_P(arg.prev_elts))
@@ -2364,7 +2364,7 @@ slicebefore_i(VALUE yielder, VALUE enumerator, int argc, VALUE *argv)
arg.yielder = yielder;if (!NIL_P(arg.state))
-
arg.state = rb_obj_dup(arg.state);
-
arg.state = rb_funcall(arg.state, id_dup, 0, 0);
rb_block_call(enumerable, id_each, 0, 0, slicebefore_ii, (VALUE)&arg);
if (!NIL_P(arg.prev_elts))
@@ -2606,5 +2606,6 @@ Init_Enumerable(void)
id_cmp = rb_intern("<=>");
id_next = rb_intern("next");
id_size = rb_intern("size"); -
id_dup = rb_intern("dup");
}
=end
Updated by matz (Yukihiro Matsumoto) over 14 years ago
=begin
Hi,
In message "Re: [ruby-core:29026] [Bug #3016] Enumerable#slice_before and dup"
on Fri, 26 Mar 2010 14:02:05 +0900, Marc-Andre Lafortune redmine@ruby-lang.org writes:
|When writing the specs for slice_before, I was surprised that it doesn't call #dup.
MRI often bypasses method calls using direct C function call, mostly
for performance reason. I am afraid that it's too late to fix all
"surprises". I say it's implementation dependent behavior. I think
it is over specification to check.
matz.
=end
Updated by mame (Yusuke Endoh) over 14 years ago
- Status changed from Open to Rejected