matz (Yukihiro Matsumoto) wrote: > Sounds OK. One concern left is `Hash#filter`. > ... I have added a bug to discuss the discrepancy in Hash's behavior: https://bugs.ruby-lang.org/issues/13795davidarnold (David Arnold)
> I expect Set to act almost like Array [...] But why? Aside from both being collections, there is no connection. Ruby's Set isn't even implemented with an Array. The core mathematical definition of Set is based on element member...davidarnold (David Arnold)
> In the worst case, ruby 3.x may accept backwards-incompatible changes so either way > ... I fully agree that changing Hash#select and #reject (or even #find_all) should not be a 2.x change!davidarnold (David Arnold)
> > Also, as a side note, it seems that Hash#select and #reject really are the only two methods that behave this way. And even inside Hash, methods like #collect, #collect_concat, #drop, #drop_while, #grep, #max, #max_by, #min, #min_by...davidarnold (David Arnold)
In Ruby, the main reason you would use protected instead of private is because you want different instances of the same class lineage to be able to access the method. However, the rules around protected (callable only where self of th...davidarnold (David Arnold)
In keeping with other class semantics, Set should implement an inclusion / membership test for #===. For example with Range: ~~~ ruby (1..3) === 2 #=> true ~~~ Desired behavior: ~~~ ruby Set[1, 2, 3] === 2 #=> true ~~~ ...davidarnold (David Arnold)
I did some research to explore the idea that *more* Enumerable classes should implement #select (and even #collect, #drop, etc) to return their own type, since that sounds appealing on the surface. While classes like Array, Hash, and ...davidarnold (David Arnold)
> I would like to suggest a third possible option: if Hash#select returning a Hash is useful, why not expand on this so that one of them always returns the input data structure? So, I think people do like having a way to get the same ...davidarnold (David Arnold)
> This might make the next version of Ruby not backwards-compatible in some instances. It might be better to leave the methods as they are. Ruby has been not backwards-compatible in several releases, so I don't see that as a reason pe...davidarnold (David Arnold)