From: naitoh@... Date: 2018-04-27T23:58:33+00:00 Subject: [ruby-core:86740] [Ruby trunk Feature#14701] If the object is not frozen, I want to be able to redefine the compound assignment operator. Issue #14701 has been updated by naitoh (Jun NAITOH). matz (Yukihiro Matsumoto) wrote: > Use `append` instead of `+=` for arrays. Changing the behavior of `+=` would have too much compatibility problems from side-effect. > > Matz. Thank you for your reply. I am sorry if it caused me to misunderstand what I meant to say by writing "the object is not frozen". > Matz rejected this in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/9127, > but I do not completely understand the reason. I wanted to continue with the discussion in 9127 above. I do not want to change (redefine) the behavior of +=, -=, *=, /=, %= against Array. I only want to define the behavior of +=, -=, *=, /=, %= (etc..) for Numo::NArray class. Why does the compatibility problem occur as a side effect of enabling this definition for Numo::NArray class? Is that a matter of performance? masa16 (Masahiro Tanaka) wrote: > I think it is enough to change the meaning of > > ~~~ ruby > x += a > ~~~ > > to > > ~~~ ruby > if x.respond_to?(:'+=') > x.send(:'+=',a) > else > x = x + a > end > ~~~ > > Matz rejected this in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/9127, > but I do not completely understand the reason. That is exactly what I want. Although there are concerns about performance problems, I could not understand that compatibility problems arise. Eregon (Benoit Daloze) wrote: > because a += b is no longer a = a + b but sometimes something completely different and there is no way to differentiate at the source level. I think it can easily be distinguished. > Most notably, it means other variables pointing to the same NArray would get modified in place by +=, which seems highly unexpected. I think that only people using Numo::NArray should pay attention. mame (Yusuke Endoh) wrote: > ``` > >>> a = [] > >>> b = a > >>> a += [1,2,3] > >>> b > [1, 2, 3] > ``` > > Most Rubyists know and expect that `Array#+` is non-destructive, so I think that it is unacceptable to allow this. Yes, I agree with this point. However, I would like to discuss `Numo::NArray#+=`, not `Array#+`(or `Array#+=`). If it is a different class, is it strange to behave differently for that class?. ---------------------------------------- Feature #14701: If the object is not frozen, I want to be able to redefine the compound assignment operator. https://bugs.ruby-lang.org/issues/14701#change-71695 * Author: naitoh (Jun NAITOH) * Status: Rejected * Priority: Normal * Assignee: * Target version: ---------------------------------------- If the object is not frozen, I want to be able to redefine the compound assignment operator (e.g. +=, -=, *=, /=, ..etc ). https://docs.ruby-lang.org/ja/latest/doc/spec=2foperator.html * Redefinable operator (method) ~~~ | ^ & <=> == === =~ > >= < <= << >> + - * / % ** ~ +@ -@ [] []= ` ! != !~ ~~~ * use case ~~~ > require 'numo/narray' > a = Numo::Int32[5, 6] => Numo::Int32#shape=[2] [5, 6] > a.object_id => 70326927544920 > a += 1 => Numo::Int32#shape=[2] [6, 7] > a.object_id => 70326927530540 > a.inplace + 1 => Numo::Int32(view)#shape=[2] [7, 8] > a.object_id => 70326927530540 ~~~ With Numo::NArray, using "inplace" instead of "+=" will update the same object so it will be faster. I want to write "a += 1" instead of "a.inplace + 1". However, Ruby can not redefine "+=". -- https://bugs.ruby-lang.org/ Unsubscribe: