You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After dropping an element from an Enumerable I expect that the remaining elements are the same as in the original Enumerable. Calling #drop should not modify the elements.
Calling #drop on an Enumerable calls #dup on every non-dropped element. Besides the side-effect illustrated above it also expensive to do all that copying, and it doesn't work with objects whose #dup doesn't behave well, or objects that can't be #dup'ed.
I discovered this while writing a native extension with a class that was not allocatable. It took me a while to understand why my code failed with errors saying that my class wasn't allocatable – I wasn't trying to create instances.
It looks like this behaviour was introduced in 06f0441, but it seems like the fix for the problem described in the commit message was applied in the wrong place (it ended up in Enumerable instead of Enumerator).
Environment
jruby 9.1.5.0 (2.3.1) 2016-09-07 036ce39 Java HotSpot(TM) 64-Bit Server VM 25.0-b70 on 1.8.0-b132 +jit [darwin-x86_64]
jruby 1.7.25 (1.9.3p551) 2016-04-13 867cb81 on Java HotSpot(TM) 64-Bit Server VM 1.8.0-b132 +jit [darwin-x86_64]
The text was updated successfully, but these errors were encountered:
I'd like to, but I'm not sure I could do it without creating more bugs. I don't really understand the reasoning behind why it works the way it works now (for example: why only #drop, why wouldn't it be a problem with #take too?). I can make an attempt, but I can't promise that it will happen quickly.
The fix seems to be to change Signature.NO_ARGUMENTS to Signature.ONE_REQUIRED (in 9K, Arity.ON_REQUIRED in 1.7), which I don't understand the mechanics behind. I've opened two PRs with fixes #4225 & #4226.
Given:
Expected Behavior
After dropping an element from an
Enumerable
I expect that the remaining elements are the same as in the originalEnumerable
. Calling#drop
should not modify the elements.Actual Behavior
Calling
#drop
on anEnumerable
calls#dup
on every non-dropped element. Besides the side-effect illustrated above it also expensive to do all that copying, and it doesn't work with objects whose#dup
doesn't behave well, or objects that can't be#dup
'ed.I discovered this while writing a native extension with a class that was not allocatable. It took me a while to understand why my code failed with errors saying that my class wasn't allocatable – I wasn't trying to create instances.
It looks like this behaviour was introduced in 06f0441, but it seems like the fix for the problem described in the commit message was applied in the wrong place (it ended up in
Enumerable
instead ofEnumerator
).Environment
The text was updated successfully, but these errors were encountered: