Daniele Alessandri
2009-Apr-20 19:46 UTC
[Ironruby-core] More fixes for core/array specs (again)
Hi, I have attached a diff with new fixes for a whole bunch of failing expectations in the core/array specs. * Slightly modified IListOps.UniqueSelf as suggested upon review. * Fixed IListOps.ReverseIndex as Array#rindex should not fail if elements are removed from the array during the iteration over its elements. * Changed IListOps.Reverse to return IList instances of the same type of the given self argument (this change also fixes the following failing spec: "Array#reverse returns subclass instance on Array subclasses") * Changed IListOps.SetElement to make it try to invoke #to_ary on its argument for multi-element sets. * Changed one overload of IListOps.Equals to make it try to call #to_ary on the object argument of Array#== and use the resulting array as the actual argument for the equality check. * Cleaning up tags removing expectations that do not fail anymore. * Added ArrayOps.ToAry as Array#to_a and Array#to_ary behave differently on subclasses of arrays. * Various changes to IListOps.Join to clear all of the remaining tags for the specs of Array#join. The tags marked as critical in join_tags.txt are not related to pending bugs for Array#join. * Changed IListOps.Repetition to return IList instances of the same type of the given self argument (this fixes also "Array#* with an integer returns subclass instance with Array subclasses") * Modified IListOps.RecursiveJoin to make it flag the resulting string as tainted if the given array, at least one of its elements or the separator string are tainted. * IListOps.Difference now uses Object#hash and Object#eql? to check for object equality, this fixes the failing spec "Array#- acts as if using an intermediate hash to collect values" These changes directly clear the following failing expectations: Array#[]= calls to_ary on its rhs argument for multi-element sets Array#== calls to_ary on its argument Array#join tries to convert the passed seperator to a String using #to_str Array#join checks whether the passed seperator responds to #to_str Array#join handles recursive arrays Array#join does not consider taint of either the array or the separator when the array is empty Array#join returns a string which would be infected with taint of the array, its elements or the separator when the array is not empty Array#join does not process the separator if the array is empty Array#join raises a TypeError if the passed separator is not a string and does not respond to #to_str Array#- acts as if using an intermediate hash to collect values Array#* with an integer returns subclass instance with Array subclasses Array#* with an integer copies the taint status of the original array even if the array is empty Array#* with an integer copies the taint status of the original array if the passed count is not 0 Array#* with a string returns a string which would be infected with taint of the array, its elements or the separator when the array is not empty Array#reverse returns subclass instance on Array subclasses Array#rindex does not fail when removing elements from block I have only a question: I''ve made changes to IListOps.Reverse and IListOps.Repetition in order to make them return IList instead of RubyArray. In ruby, Array#reverse and Array#* maintain the same type of self for the returning object (that is, if self is a RubyArray.Subclass then it is returned a new object of the same type). With these changes we would actually be able to do something like this:>>> arraylist = System::Collections::ArrayList.new([1,2,3,4,5])=> [1, 2, 3, 4, 5]>>> multiplied_arraylist = arraylist * 2=> [1, 2, 3, 4, 5, 1, 2, 3, 4, 5]>>> multiplied_arraylist.class=> System::Collections::ArrayList Would it be a consistent behaviour? On a (partially) unrelated note, I''ve just noticed that List<T>.Reverse is more like Array#reverse! but it actually take the precedence over IListOps.Reverse. I''m just thinking if this could lead to some sort of confusion (ohan I''m not sure if anything can be done about this. Thanks, Daniele PS: I''m waiting to push these changes on my remote repository, Jim told he is going to pull today but I would like to wait for a review first (and yeah, today I''m too lazy to actually start off a new branch :-)). -- Daniele Alessandri http://www.clorophilla.net/blog/ http://twitter.com/JoL1hAHN -------------- next part -------------- A non-text attachment was scrubbed... Name: core-array_fixes090420.diff Type: application/octet-stream Size: 53958 bytes Desc: not available URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090420/4befd1ca/attachment.obj>
Looks great! Could you copy the comment "# MRI follows hashing semantics here, so doesn''t actually call eql?/hash for Fixnum/Symbol" from core\array\minus_spec.rb to IListOps.Difference as its not obvious why the code in IListOps.Difference does the complicated checks. Yes, it seems OK that you can call all the Array methods on System::Collections::ArrayList (and any System::Collectinos::IList object in general). We are exposing Ruby String methods on System::String, and it would be consistent with that approach. About List<T>.Reverse, you could argue that if you use Ruby casing of "reverse", IListOps should get precedence. Could you open a bug for this please? If you use "Reverse", then the CLR method should get precedence, and there would be a possibility of confusion, but as you say, there is not much that can be done. It does not seem worth special-casing. Thanks, Shri -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele Alessandri Sent: Monday, April 20, 2009 12:46 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] More fixes for core/array specs (again) Hi, I have attached a diff with new fixes for a whole bunch of failing expectations in the core/array specs. * Slightly modified IListOps.UniqueSelf as suggested upon review. * Fixed IListOps.ReverseIndex as Array#rindex should not fail if elements are removed from the array during the iteration over its elements. * Changed IListOps.Reverse to return IList instances of the same type of the given self argument (this change also fixes the following failing spec: "Array#reverse returns subclass instance on Array subclasses") * Changed IListOps.SetElement to make it try to invoke #to_ary on its argument for multi-element sets. * Changed one overload of IListOps.Equals to make it try to call #to_ary on the object argument of Array#== and use the resulting array as the actual argument for the equality check. * Cleaning up tags removing expectations that do not fail anymore. * Added ArrayOps.ToAry as Array#to_a and Array#to_ary behave differently on subclasses of arrays. * Various changes to IListOps.Join to clear all of the remaining tags for the specs of Array#join. The tags marked as critical in join_tags.txt are not related to pending bugs for Array#join. * Changed IListOps.Repetition to return IList instances of the same type of the given self argument (this fixes also "Array#* with an integer returns subclass instance with Array subclasses") * Modified IListOps.RecursiveJoin to make it flag the resulting string as tainted if the given array, at least one of its elements or the separator string are tainted. * IListOps.Difference now uses Object#hash and Object#eql? to check for object equality, this fixes the failing spec "Array#- acts as if using an intermediate hash to collect values" These changes directly clear the following failing expectations: Array#[]= calls to_ary on its rhs argument for multi-element sets Array#== calls to_ary on its argument Array#join tries to convert the passed seperator to a String using #to_str Array#join checks whether the passed seperator responds to #to_str Array#join handles recursive arrays Array#join does not consider taint of either the array or the separator when the array is empty Array#join returns a string which would be infected with taint of the array, its elements or the separator when the array is not empty Array#join does not process the separator if the array is empty Array#join raises a TypeError if the passed separator is not a string and does not respond to #to_str Array#- acts as if using an intermediate hash to collect values Array#* with an integer returns subclass instance with Array subclasses Array#* with an integer copies the taint status of the original array even if the array is empty Array#* with an integer copies the taint status of the original array if the passed count is not 0 Array#* with a string returns a string which would be infected with taint of the array, its elements or the separator when the array is not empty Array#reverse returns subclass instance on Array subclasses Array#rindex does not fail when removing elements from block I have only a question: I''ve made changes to IListOps.Reverse and IListOps.Repetition in order to make them return IList instead of RubyArray. In ruby, Array#reverse and Array#* maintain the same type of self for the returning object (that is, if self is a RubyArray.Subclass then it is returned a new object of the same type). With these changes we would actually be able to do something like this:>>> arraylist = System::Collections::ArrayList.new([1,2,3,4,5])=> [1, 2, 3, 4, 5]>>> multiplied_arraylist = arraylist * 2=> [1, 2, 3, 4, 5, 1, 2, 3, 4, 5]>>> multiplied_arraylist.class=> System::Collections::ArrayList Would it be a consistent behaviour? On a (partially) unrelated note, I''ve just noticed that List<T>.Reverse is more like Array#reverse! but it actually take the precedence over IListOps.Reverse. I''m just thinking if this could lead to some sort of confusion (ohan I''m not sure if anything can be done about this. Thanks, Daniele PS: I''m waiting to push these changes on my remote repository, Jim told he is going to pull today but I would like to wait for a review first (and yeah, today I''m too lazy to actually start off a new branch :-)). -- Daniele Alessandri http://www.clorophilla.net/blog/ http://twitter.com/JoL1hAHN
Daniele, If you push this out tonight, I''ll pull it in tomorrow. JD> -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Shri Borde > Sent: Monday, April 20, 2009 9:58 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] More fixes for core/array specs (again) > > Looks great! > > Could you copy the comment "# MRI follows hashing semantics here, so > doesn''t actually call eql?/hash for Fixnum/Symbol" from > core\array\minus_spec.rb to IListOps.Difference as its not obvious why > the code in IListOps.Difference does the complicated checks. > > Yes, it seems OK that you can call all the Array methods on > System::Collections::ArrayList (and any System::Collectinos::IList > object in general). We are exposing Ruby String methods on > System::String, and it would be consistent with that approach. > > About List<T>.Reverse, you could argue that if you use Ruby casing of > "reverse", IListOps should get precedence. Could you open a bug for > this please? If you use "Reverse", then the CLR method should get > precedence, and there would be a possibility of confusion, but as you > say, there is not much that can be done. It does not seem worth > special-casing. > > Thanks, > Shri > > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Daniele Alessandri > Sent: Monday, April 20, 2009 12:46 PM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] More fixes for core/array specs (again) > > Hi, > I have attached a diff with new fixes for a whole bunch of failing > expectations in the core/array specs. > > * Slightly modified IListOps.UniqueSelf as suggested upon review. > * Fixed IListOps.ReverseIndex as Array#rindex should not fail if > elements are removed from the array during the iteration over its > elements. > * Changed IListOps.Reverse to return IList instances of the same type > of the given self argument (this change also fixes the following > failing spec: "Array#reverse returns subclass instance on Array > subclasses") > * Changed IListOps.SetElement to make it try to invoke #to_ary on its > argument for multi-element sets. > * Changed one overload of IListOps.Equals to make it try to call > #to_ary on the object argument of Array#== and use the resulting array > as the actual argument for the equality check. > * Cleaning up tags removing expectations that do not fail anymore. > * Added ArrayOps.ToAry as Array#to_a and Array#to_ary behave > differently on subclasses of arrays. > * Various changes to IListOps.Join to clear all of the remaining tags > for the specs of Array#join. The tags marked as critical in > join_tags.txt are not related to pending bugs for Array#join. > * Changed IListOps.Repetition to return IList instances of the same > type of the given self argument (this fixes also "Array#* with an > integer returns subclass instance with Array subclasses") > * Modified IListOps.RecursiveJoin to make it flag the resulting string > as tainted if the given array, at least one of its elements or the > separator string are tainted. > * IListOps.Difference now uses Object#hash and Object#eql? to check for > object equality, this fixes the failing spec "Array#- acts as if using > an intermediate hash to collect values" > > These changes directly clear the following failing expectations: > > Array#[]= calls to_ary on its rhs argument for multi-element sets > Array#== calls to_ary on its argument Array#join tries to convert the > passed seperator to a String using #to_str Array#join checks whether > the passed seperator responds to #to_str Array#join handles recursive > arrays Array#join does not consider taint of either the array or the > separator when the array is empty Array#join returns a string which > would be infected with taint of the array, its elements or the > separator when the array is not empty Array#join does not process the > separator if the array is empty Array#join raises a TypeError if the > passed separator is not a string and does not respond to #to_str > Array#- acts as if using an intermediate hash to collect values > Array#* with an integer returns subclass instance with Array subclasses > Array#* with an integer copies the taint status of the original array > even if the array is empty > Array#* with an integer copies the taint status of the original array > if the passed count is not 0 > Array#* with a string returns a string which would be infected with > taint of the array, its elements or the separator when the array is not > empty Array#reverse returns subclass instance on Array subclasses > Array#rindex does not fail when removing elements from block > > I have only a question: I''ve made changes to IListOps.Reverse and > IListOps.Repetition in order to make them return IList instead of > RubyArray. In ruby, Array#reverse and Array#* maintain the same type of > self for the returning object (that is, if self is a RubyArray.Subclass > then it is returned a new object of the same type). > With these changes we would actually be able to do something like > this: > > >>> arraylist = System::Collections::ArrayList.new([1,2,3,4,5]) > => [1, 2, 3, 4, 5] > >>> multiplied_arraylist = arraylist * 2 > => [1, 2, 3, 4, 5, 1, 2, 3, 4, 5] > >>> multiplied_arraylist.class > => System::Collections::ArrayList > > Would it be a consistent behaviour? > > On a (partially) unrelated note, I''ve just noticed that List<T>.Reverse > is more like Array#reverse! but it actually take the precedence over > IListOps.Reverse. I''m just thinking if this could lead to some sort of > confusion (ohan I''m not sure if anything can be done about this. > > Thanks, > Daniele > > > PS: I''m waiting to push these changes on my remote repository, Jim told > he is going to pull today but I would like to wait for a review first > (and yeah, today I''m too lazy to actually start off a new branch :-)). > > -- > Daniele Alessandri > http://www.clorophilla.net/blog/ > http://twitter.com/JoL1hAHN > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
Daniele Alessandri
2009-Apr-21 11:43 UTC
[Ironruby-core] More fixes for core/array specs (again)
Right now I don''t have access to my local repository, I think to be able to push on github by 9:00 PM CEST (UTC+2, that''s my timezone, it should be 12:00 PM PDT). On Tue, Apr 21, 2009 at 08:39, Jim Deville <jdeville at microsoft.com> wrote:> Daniele, > > If you push this out tonight, I''ll pull it in tomorrow. > > JD > >> -----Original Message----- >> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- >> bounces at rubyforge.org] On Behalf Of Shri Borde >> Sent: Monday, April 20, 2009 9:58 PM >> To: ironruby-core at rubyforge.org >> Subject: Re: [Ironruby-core] More fixes for core/array specs (again) >> >> Looks great! >> >> Could you copy the comment "# MRI follows hashing semantics here, so >> doesn''t actually call eql?/hash for Fixnum/Symbol" from >> core\array\minus_spec.rb to IListOps.Difference as its not obvious why >> the code in IListOps.Difference does the complicated checks. >> >> Yes, it seems OK that you can call all the Array methods on >> System::Collections::ArrayList (and any System::Collectinos::IList >> object in general). We are exposing Ruby String methods on >> System::String, and it would be consistent with that approach. >> >> About List<T>.Reverse, you could argue that if you use Ruby casing of >> "reverse", IListOps should get precedence. Could you open a bug for >> this please? If you use "Reverse", then the CLR method should get >> precedence, and there would be a possibility of confusion, but as you >> say, there is not much that can be done. It does not seem worth >> special-casing. >> >> Thanks, >> Shri >> >> >> -----Original Message----- >> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- >> bounces at rubyforge.org] On Behalf Of Daniele Alessandri >> Sent: Monday, April 20, 2009 12:46 PM >> To: ironruby-core at rubyforge.org >> Subject: [Ironruby-core] More fixes for core/array specs (again) >> >> Hi, >> I have attached a diff with new fixes for a whole bunch of failing >> expectations in the core/array specs. >> >> * Slightly modified IListOps.UniqueSelf as suggested upon review. >> * Fixed IListOps.ReverseIndex as Array#rindex should not fail if >> elements are removed from the array during the iteration over its >> elements. >> * Changed IListOps.Reverse to return IList instances of the same type >> of the given self argument (this change also fixes the following >> failing spec: "Array#reverse returns subclass instance on Array >> subclasses") >> * Changed IListOps.SetElement to make it try to invoke #to_ary on its >> argument for multi-element sets. >> * Changed one overload of IListOps.Equals to make it try to call >> #to_ary on the object argument of Array#== and use the resulting array >> as the actual argument for the equality check. >> * Cleaning up tags removing expectations that do not fail anymore. >> * Added ArrayOps.ToAry as Array#to_a and Array#to_ary behave >> differently on subclasses of arrays. >> * Various changes to IListOps.Join to clear all of the remaining tags >> for the specs of Array#join. The tags marked as critical in >> join_tags.txt are not related to pending bugs for Array#join. >> * Changed IListOps.Repetition to return IList instances of the same >> type of the given self argument (this fixes also "Array#* with an >> integer returns subclass instance with Array subclasses") >> * Modified IListOps.RecursiveJoin to make it flag the resulting string >> as tainted if the given array, at least one of its elements or the >> separator string are tainted. >> * IListOps.Difference now uses Object#hash and Object#eql? to check for >> object equality, this fixes the failing spec "Array#- acts as if using >> an intermediate hash to collect values" >> >> These changes directly clear the following failing expectations: >> >> Array#[]= calls to_ary on its rhs argument for multi-element sets >> Array#== calls to_ary on its argument Array#join tries to convert the >> passed seperator to a String using #to_str Array#join checks whether >> the passed seperator responds to #to_str Array#join handles recursive >> arrays Array#join does not consider taint of either the array or the >> separator when the array is empty Array#join returns a string which >> would be infected with taint of the array, its elements or the >> separator when the array is not empty Array#join does not process the >> separator if the array is empty Array#join raises a TypeError if the >> passed separator is not a string and does not respond to #to_str >> Array#- acts as if using an ?intermediate hash to collect values >> Array#* with an integer returns subclass instance with Array subclasses >> Array#* with an integer copies the taint status of the original array >> even if the array is empty >> Array#* with an integer copies the taint status of the original array >> if the passed count is not 0 >> Array#* with a string returns a string which would be infected with >> taint of the array, its elements or the separator when the array is not >> empty Array#reverse returns subclass instance on Array subclasses >> Array#rindex does not fail when removing elements from block >> >> I have only a question: I''ve made changes to IListOps.Reverse and >> IListOps.Repetition in order to make them return IList instead of >> RubyArray. In ruby, Array#reverse and Array#* maintain the same type of >> self for the returning object (that is, if self is a RubyArray.Subclass >> then it is returned a new object of the same type). >> With these changes we would actually be able to do something like >> this: >> >> >>> arraylist = System::Collections::ArrayList.new([1,2,3,4,5]) >> => [1, 2, 3, 4, 5] >> >>> multiplied_arraylist = arraylist * 2 >> => [1, 2, 3, 4, 5, 1, 2, 3, 4, 5] >> >>> multiplied_arraylist.class >> => System::Collections::ArrayList >> >> Would it be a consistent behaviour? >> >> On a (partially) unrelated note, I''ve just noticed that List<T>.Reverse >> is more like Array#reverse! but it actually take the precedence over >> IListOps.Reverse. I''m just thinking if this could lead to some sort of >> confusion (ohan I''m not sure if anything can be done about this. >> >> Thanks, >> Daniele >> >> >> PS: I''m waiting to push these changes on my remote repository, Jim told >> he is going to pull today but I would like to wait for a review first >> (and yeah, today I''m too lazy to actually start off a new branch :-)). >> >> -- >> Daniele Alessandri >> http://www.clorophilla.net/blog/ >> http://twitter.com/JoL1hAHN >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-- Daniele Alessandri http://www.clorophilla.net/blog/ http://twitter.com/JoL1hAHN
Daniele Alessandri
2009-Apr-21 11:58 UTC
[Ironruby-core] More fixes for core/array specs (again)
OK I''ll add that comment to IListOps.Difference.>From what I''ve seen yesterday "reverse" and "Reverse" both call theCLR method of List<T>, I''ll try again later to confirm this behaviour just to be really sure before I open a bug. Thanks, Daniele On Tue, Apr 21, 2009 at 06:57, Shri Borde <Shri.Borde at microsoft.com> wrote:> Looks great! > > Could you copy the comment "# MRI follows hashing semantics here, so doesn''t actually call eql?/hash for Fixnum/Symbol" from core\array\minus_spec.rb to IListOps.Difference as its not obvious why the code in IListOps.Difference does the complicated checks. > > Yes, it seems OK that you can call all the Array methods on System::Collections::ArrayList (and any System::Collectinos::IList object in general). We are exposing Ruby String methods on System::String, and it would be consistent with that approach. > > About List<T>.Reverse, you could argue that if you use Ruby casing of "reverse", IListOps should get precedence. Could you open a bug for this please? If you use "Reverse", then the CLR method should get precedence, and there would be a possibility of confusion, but as you say, there is not much that can be done. It does not seem worth special-casing. > > Thanks, > Shri > > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele Alessandri > Sent: Monday, April 20, 2009 12:46 PM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] More fixes for core/array specs (again) > > Hi, > I have attached a diff with new fixes for a whole bunch of failing expectations in the core/array specs. > > * Slightly modified IListOps.UniqueSelf as suggested upon review. > * Fixed IListOps.ReverseIndex as Array#rindex should not fail if elements are removed from the array during the iteration over its elements. > * Changed IListOps.Reverse to return IList instances of the same type of the given self argument (this change also fixes the following failing spec: "Array#reverse returns subclass instance on Array > subclasses") > * Changed IListOps.SetElement to make it try to invoke #to_ary on its argument for multi-element sets. > * Changed one overload of IListOps.Equals to make it try to call #to_ary on the object argument of Array#== and use the resulting array as the actual argument for the equality check. > * Cleaning up tags removing expectations that do not fail anymore. > * Added ArrayOps.ToAry as Array#to_a and Array#to_ary behave differently on subclasses of arrays. > * Various changes to IListOps.Join to clear all of the remaining tags for the specs of Array#join. The tags marked as critical in join_tags.txt are not related to pending bugs for Array#join. > * Changed IListOps.Repetition to return IList instances of the same type of the given self argument (this fixes also "Array#* with an integer returns subclass instance with Array subclasses") > * Modified IListOps.RecursiveJoin to make it flag the resulting string as tainted if the given array, at least one of its elements or the separator string are tainted. > * IListOps.Difference now uses Object#hash and Object#eql? to check for object equality, this fixes the failing spec "Array#- acts as if using an intermediate hash to collect values" > > These changes directly clear the following failing expectations: > > Array#[]= calls to_ary on its rhs argument for multi-element sets Array#== calls to_ary on its argument Array#join tries to convert the passed seperator to a String using #to_str Array#join checks whether the passed seperator responds to #to_str Array#join handles recursive arrays Array#join does not consider taint of either the array or the separator when the array is empty Array#join returns a string which would be infected with taint of the array, its elements or the separator when the array is not empty Array#join does not process the separator if the array is empty Array#join raises a TypeError if the passed separator is not a string and does not respond to #to_str > Array#- acts as if using an ?intermediate hash to collect values > Array#* with an integer returns subclass instance with Array subclasses > Array#* with an integer copies the taint status of the original array even if the array is empty > Array#* with an integer copies the taint status of the original array if the passed count is not 0 > Array#* with a string returns a string which would be infected with taint of the array, its elements or the separator when the array is not empty Array#reverse returns subclass instance on Array subclasses Array#rindex does not fail when removing elements from block > > I have only a question: I''ve made changes to IListOps.Reverse and IListOps.Repetition in order to make them return IList instead of RubyArray. In ruby, Array#reverse and Array#* maintain the same type of self for the returning object (that is, if self is a RubyArray.Subclass then it is returned a new object of the same type). > With these changes we would actually be able to do something like > this: > >>>> arraylist = System::Collections::ArrayList.new([1,2,3,4,5]) > => [1, 2, 3, 4, 5] >>>> multiplied_arraylist = arraylist * 2 > => [1, 2, 3, 4, 5, 1, 2, 3, 4, 5] >>>> multiplied_arraylist.class > => System::Collections::ArrayList > > Would it be a consistent behaviour? > > On a (partially) unrelated note, I''ve just noticed that List<T>.Reverse is more like Array#reverse! but it actually take the precedence over IListOps.Reverse. I''m just thinking if this could lead to some sort of confusion (ohan I''m not sure if anything can be done about this. > > Thanks, > Daniele > > > PS: I''m waiting to push these changes on my remote repository, Jim told he is going to pull today but I would like to wait for a review first (and yeah, today I''m too lazy to actually start off a new branch :-)). > > -- > Daniele Alessandri > http://www.clorophilla.net/blog/ > http://twitter.com/JoL1hAHN > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-- Daniele Alessandri http://www.clorophilla.net/blog/ http://twitter.com/JoL1hAHN
Daniele Alessandri
2009-Apr-21 18:42 UTC
[Ironruby-core] More fixes for core/array specs (again)
Just pushed my changes (with the added comment to IListOps.Difference as suggested by Shri). http://github.com/nrk/ironruby/commit/722dd4d2dc233458a49f154b926ea666d2cdb324 Thanks, Daniele On Tue, Apr 21, 2009 at 13:43, Daniele Alessandri <suppakilla at gmail.com> wrote:> Right now I don''t have access to my local repository, I think to be > able to push on github by 9:00 PM CEST (UTC+2, that''s my timezone, it > should be 12:00 PM PDT). > > On Tue, Apr 21, 2009 at 08:39, Jim Deville <jdeville at microsoft.com> wrote: >> Daniele, >> >> If you push this out tonight, I''ll pull it in tomorrow. >> >> JD >> >>> -----Original Message----- >>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- >>> bounces at rubyforge.org] On Behalf Of Shri Borde >>> Sent: Monday, April 20, 2009 9:58 PM >>> To: ironruby-core at rubyforge.org >>> Subject: Re: [Ironruby-core] More fixes for core/array specs (again) >>> >>> Looks great! >>> >>> Could you copy the comment "# MRI follows hashing semantics here, so >>> doesn''t actually call eql?/hash for Fixnum/Symbol" from >>> core\array\minus_spec.rb to IListOps.Difference as its not obvious why >>> the code in IListOps.Difference does the complicated checks. >>> >>> Yes, it seems OK that you can call all the Array methods on >>> System::Collections::ArrayList (and any System::Collectinos::IList >>> object in general). We are exposing Ruby String methods on >>> System::String, and it would be consistent with that approach. >>> >>> About List<T>.Reverse, you could argue that if you use Ruby casing of >>> "reverse", IListOps should get precedence. Could you open a bug for >>> this please? If you use "Reverse", then the CLR method should get >>> precedence, and there would be a possibility of confusion, but as you >>> say, there is not much that can be done. It does not seem worth >>> special-casing. >>> >>> Thanks, >>> Shri >>> >>> >>> -----Original Message----- >>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- >>> bounces at rubyforge.org] On Behalf Of Daniele Alessandri >>> Sent: Monday, April 20, 2009 12:46 PM >>> To: ironruby-core at rubyforge.org >>> Subject: [Ironruby-core] More fixes for core/array specs (again) >>> >>> Hi, >>> I have attached a diff with new fixes for a whole bunch of failing >>> expectations in the core/array specs. >>> >>> * Slightly modified IListOps.UniqueSelf as suggested upon review. >>> * Fixed IListOps.ReverseIndex as Array#rindex should not fail if >>> elements are removed from the array during the iteration over its >>> elements. >>> * Changed IListOps.Reverse to return IList instances of the same type >>> of the given self argument (this change also fixes the following >>> failing spec: "Array#reverse returns subclass instance on Array >>> subclasses") >>> * Changed IListOps.SetElement to make it try to invoke #to_ary on its >>> argument for multi-element sets. >>> * Changed one overload of IListOps.Equals to make it try to call >>> #to_ary on the object argument of Array#== and use the resulting array >>> as the actual argument for the equality check. >>> * Cleaning up tags removing expectations that do not fail anymore. >>> * Added ArrayOps.ToAry as Array#to_a and Array#to_ary behave >>> differently on subclasses of arrays. >>> * Various changes to IListOps.Join to clear all of the remaining tags >>> for the specs of Array#join. The tags marked as critical in >>> join_tags.txt are not related to pending bugs for Array#join. >>> * Changed IListOps.Repetition to return IList instances of the same >>> type of the given self argument (this fixes also "Array#* with an >>> integer returns subclass instance with Array subclasses") >>> * Modified IListOps.RecursiveJoin to make it flag the resulting string >>> as tainted if the given array, at least one of its elements or the >>> separator string are tainted. >>> * IListOps.Difference now uses Object#hash and Object#eql? to check for >>> object equality, this fixes the failing spec "Array#- acts as if using >>> an intermediate hash to collect values" >>> >>> These changes directly clear the following failing expectations: >>> >>> Array#[]= calls to_ary on its rhs argument for multi-element sets >>> Array#== calls to_ary on its argument Array#join tries to convert the >>> passed seperator to a String using #to_str Array#join checks whether >>> the passed seperator responds to #to_str Array#join handles recursive >>> arrays Array#join does not consider taint of either the array or the >>> separator when the array is empty Array#join returns a string which >>> would be infected with taint of the array, its elements or the >>> separator when the array is not empty Array#join does not process the >>> separator if the array is empty Array#join raises a TypeError if the >>> passed separator is not a string and does not respond to #to_str >>> Array#- acts as if using an ?intermediate hash to collect values >>> Array#* with an integer returns subclass instance with Array subclasses >>> Array#* with an integer copies the taint status of the original array >>> even if the array is empty >>> Array#* with an integer copies the taint status of the original array >>> if the passed count is not 0 >>> Array#* with a string returns a string which would be infected with >>> taint of the array, its elements or the separator when the array is not >>> empty Array#reverse returns subclass instance on Array subclasses >>> Array#rindex does not fail when removing elements from block >>> >>> I have only a question: I''ve made changes to IListOps.Reverse and >>> IListOps.Repetition in order to make them return IList instead of >>> RubyArray. In ruby, Array#reverse and Array#* maintain the same type of >>> self for the returning object (that is, if self is a RubyArray.Subclass >>> then it is returned a new object of the same type). >>> With these changes we would actually be able to do something like >>> this: >>> >>> >>> arraylist = System::Collections::ArrayList.new([1,2,3,4,5]) >>> => [1, 2, 3, 4, 5] >>> >>> multiplied_arraylist = arraylist * 2 >>> => [1, 2, 3, 4, 5, 1, 2, 3, 4, 5] >>> >>> multiplied_arraylist.class >>> => System::Collections::ArrayList >>> >>> Would it be a consistent behaviour? >>> >>> On a (partially) unrelated note, I''ve just noticed that List<T>.Reverse >>> is more like Array#reverse! but it actually take the precedence over >>> IListOps.Reverse. I''m just thinking if this could lead to some sort of >>> confusion (ohan I''m not sure if anything can be done about this. >>> >>> Thanks, >>> Daniele >>> >>> >>> PS: I''m waiting to push these changes on my remote repository, Jim told >>> he is going to pull today but I would like to wait for a review first >>> (and yeah, today I''m too lazy to actually start off a new branch :-)). >>> >>> -- >>> Daniele Alessandri >>> http://www.clorophilla.net/blog/ >>> http://twitter.com/JoL1hAHN >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > > > > -- > Daniele Alessandri > http://www.clorophilla.net/blog/ > http://twitter.com/JoL1hAHN >-- Daniele Alessandri http://www.clorophilla.net/blog/ http://twitter.com/JoL1hAHN
Awesome. I just started putting the other set of changes (Shri, Daniele and Jirapong''s changes as of ~7pm yesterday) through the continuous integration troll we call SNAP. I''ll start pulling in the next set right away (Expected to be this change, my changes, and Jimmy''s changes) JD> -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Daniele Alessandri > Sent: Tuesday, April 21, 2009 11:43 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] More fixes for core/array specs (again) > > Just pushed my changes (with the added comment to IListOps.Difference > as suggested by Shri). > > http://github.com/nrk/ironruby/commit/722dd4d2dc233458a49f154b926ea666d > 2cdb324 > > Thanks, > Daniele > > > On Tue, Apr 21, 2009 at 13:43, Daniele Alessandri > <suppakilla at gmail.com> wrote: > > Right now I don''t have access to my local repository, I think to be > > able to push on github by 9:00 PM CEST (UTC+2, that''s my timezone, it > > should be 12:00 PM PDT). > > > > On Tue, Apr 21, 2009 at 08:39, Jim Deville <jdeville at microsoft.com> > wrote: > >> Daniele, > >> > >> If you push this out tonight, I''ll pull it in tomorrow. > >> > >> JD > >> > >>> -----Original Message----- > >>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > >>> bounces at rubyforge.org] On Behalf Of Shri Borde > >>> Sent: Monday, April 20, 2009 9:58 PM > >>> To: ironruby-core at rubyforge.org > >>> Subject: Re: [Ironruby-core] More fixes for core/array specs > (again) > >>> > >>> Looks great! > >>> > >>> Could you copy the comment "# MRI follows hashing semantics here, > so > >>> doesn''t actually call eql?/hash for Fixnum/Symbol" from > >>> core\array\minus_spec.rb to IListOps.Difference as its not obvious > why > >>> the code in IListOps.Difference does the complicated checks. > >>> > >>> Yes, it seems OK that you can call all the Array methods on > >>> System::Collections::ArrayList (and any System::Collectinos::IList > >>> object in general). We are exposing Ruby String methods on > >>> System::String, and it would be consistent with that approach. > >>> > >>> About List<T>.Reverse, you could argue that if you use Ruby casing > of > >>> "reverse", IListOps should get precedence. Could you open a bug for > >>> this please? If you use "Reverse", then the CLR method should get > >>> precedence, and there would be a possibility of confusion, but as > you > >>> say, there is not much that can be done. It does not seem worth > >>> special-casing. > >>> > >>> Thanks, > >>> Shri > >>> > >>> > >>> -----Original Message----- > >>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > >>> bounces at rubyforge.org] On Behalf Of Daniele Alessandri > >>> Sent: Monday, April 20, 2009 12:46 PM > >>> To: ironruby-core at rubyforge.org > >>> Subject: [Ironruby-core] More fixes for core/array specs (again) > >>> > >>> Hi, > >>> I have attached a diff with new fixes for a whole bunch of failing > >>> expectations in the core/array specs. > >>> > >>> * Slightly modified IListOps.UniqueSelf as suggested upon review. > >>> * Fixed IListOps.ReverseIndex as Array#rindex should not fail if > >>> elements are removed from the array during the iteration over its > >>> elements. > >>> * Changed IListOps.Reverse to return IList instances of the same > type > >>> of the given self argument (this change also fixes the following > >>> failing spec: "Array#reverse returns subclass instance on Array > >>> subclasses") > >>> * Changed IListOps.SetElement to make it try to invoke #to_ary on > its > >>> argument for multi-element sets. > >>> * Changed one overload of IListOps.Equals to make it try to call > >>> #to_ary on the object argument of Array#== and use the resulting > array > >>> as the actual argument for the equality check. > >>> * Cleaning up tags removing expectations that do not fail anymore. > >>> * Added ArrayOps.ToAry as Array#to_a and Array#to_ary behave > >>> differently on subclasses of arrays. > >>> * Various changes to IListOps.Join to clear all of the remaining > tags > >>> for the specs of Array#join. The tags marked as critical in > >>> join_tags.txt are not related to pending bugs for Array#join. > >>> * Changed IListOps.Repetition to return IList instances of the same > >>> type of the given self argument (this fixes also "Array#* with an > >>> integer returns subclass instance with Array subclasses") > >>> * Modified IListOps.RecursiveJoin to make it flag the resulting > string > >>> as tainted if the given array, at least one of its elements or the > >>> separator string are tainted. > >>> * IListOps.Difference now uses Object#hash and Object#eql? to check > for > >>> object equality, this fixes the failing spec "Array#- acts as if > using > >>> an intermediate hash to collect values" > >>> > >>> These changes directly clear the following failing expectations: > >>> > >>> Array#[]= calls to_ary on its rhs argument for multi-element sets > >>> Array#== calls to_ary on its argument Array#join tries to convert > the > >>> passed seperator to a String using #to_str Array#join checks > whether > >>> the passed seperator responds to #to_str Array#join handles > recursive > >>> arrays Array#join does not consider taint of either the array or > the > >>> separator when the array is empty Array#join returns a string which > >>> would be infected with taint of the array, its elements or the > >>> separator when the array is not empty Array#join does not process > the > >>> separator if the array is empty Array#join raises a TypeError if > the > >>> passed separator is not a string and does not respond to #to_str > >>> Array#- acts as if using an intermediate hash to collect values > >>> Array#* with an integer returns subclass instance with Array > subclasses > >>> Array#* with an integer copies the taint status of the original > array > >>> even if the array is empty > >>> Array#* with an integer copies the taint status of the original > array > >>> if the passed count is not 0 > >>> Array#* with a string returns a string which would be infected with > >>> taint of the array, its elements or the separator when the array is > not > >>> empty Array#reverse returns subclass instance on Array subclasses > >>> Array#rindex does not fail when removing elements from block > >>> > >>> I have only a question: I''ve made changes to IListOps.Reverse and > >>> IListOps.Repetition in order to make them return IList instead of > >>> RubyArray. In ruby, Array#reverse and Array#* maintain the same > type of > >>> self for the returning object (that is, if self is a > RubyArray.Subclass > >>> then it is returned a new object of the same type). > >>> With these changes we would actually be able to do something like > >>> this: > >>> > >>> >>> arraylist = System::Collections::ArrayList.new([1,2,3,4,5]) > >>> => [1, 2, 3, 4, 5] > >>> >>> multiplied_arraylist = arraylist * 2 > >>> => [1, 2, 3, 4, 5, 1, 2, 3, 4, 5] > >>> >>> multiplied_arraylist.class > >>> => System::Collections::ArrayList > >>> > >>> Would it be a consistent behaviour? > >>> > >>> On a (partially) unrelated note, I''ve just noticed that > List<T>.Reverse > >>> is more like Array#reverse! but it actually take the precedence > over > >>> IListOps.Reverse. I''m just thinking if this could lead to some sort > of > >>> confusion (ohan I''m not sure if anything can be done about this. > >>> > >>> Thanks, > >>> Daniele > >>> > >>> > >>> PS: I''m waiting to push these changes on my remote repository, Jim > told > >>> he is going to pull today but I would like to wait for a review > first > >>> (and yeah, today I''m too lazy to actually start off a new branch :- > )). > >>> > >>> -- > >>> Daniele Alessandri > >>> http://www.clorophilla.net/blog/ > >>> http://twitter.com/JoL1hAHN > >>> _______________________________________________ > >>> Ironruby-core mailing list > >>> Ironruby-core at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > >> _______________________________________________ > >> Ironruby-core mailing list > >> Ironruby-core at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > > > > > > > > -- > > Daniele Alessandri > > http://www.clorophilla.net/blog/ > > http://twitter.com/JoL1hAHN > > > > > > -- > Daniele Alessandri > http://www.clorophilla.net/blog/ > http://twitter.com/JoL1hAHN > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core