JRuby

[1.9] Array improvements to solve several specs

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.4
  • Component/s: Ruby 1.9.2
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    2

Description

Fix several specs for ruby 1.9 mode:

Subject: [PATCH] [1.9] Array#frozen? returns false for an array being sorted by #sort!
Subject: [PATCH] [1.9] Array.collect returns an Enumerator when no block given
Subject: [PATCH] [1.9] Array#choice should raise a NoMethodError when array is empty
Subject: [PATCH] [1.9] Array keeps untrusted status even if all elements are removed
Subject: [PATCH] [1.9] Array.concat raises a RuntimeError when Array is frozen and modification occurs
Subject: [PATCH] [1.9] Array.flatten! raises a RuntimeError on frozen arrays
Subject: [PATCH] [1.9] Array.push raises a RuntimeError on a frozen array
Subject: [PATCH] [1.9] Array.unshift raises a RuntimeError on a frozen array
Subject: [PATCH] [1.9] Array.uniq! raises a RuntimeError on a frozen array
Subject: [PATCH] [1.9] Array.map returns an Enumerator when no block given
Subject: [PATCH] [1.9] Array#insert raises a RuntimeError on frozen arrays
Subject: [PATCH] [1.9] Array#join raises an ArgumentError when the Array is recursive
Subject: [PATCH] [1.9] Array#join returns a string which would be infected with untrustworthiness of the array, its elements or the separator when the array is not empty

  1. array_spec_v_2.patch
    22/Sep/09 3:44 PM
    13 kB
    David Calavera
  2. array_specs.patch
    22/Sep/09 3:51 AM
    13 kB
    David Calavera

Activity

Hide
David Calavera added a comment -

I forgot to add a commit, fixed

Show
David Calavera added a comment - I forgot to add a commit, fixed
Hide
Marcin Mielzynski added a comment -

I can see lots of runtime checks against runtime.is1_9() in your patch. You should always be able to avoid them by for example wrapping 1.9 method around 1.8 one.

Show
Marcin Mielzynski added a comment - I can see lots of runtime checks against runtime.is1_9() in your patch. You should always be able to avoid them by for example wrapping 1.9 method around 1.8 one.
Hide
David Calavera added a comment -

I've modified the patch to wrap ruby 1.9 methods around 1.8 methods and remove most of the check statements, some of them are in the middle of a method and I think wrap those could be a worst solution.

Show
David Calavera added a comment - I've modified the patch to wrap ruby 1.9 methods around 1.8 methods and remove most of the check statements, some of them are in the middle of a method and I think wrap those could be a worst solution.
Hide
David Calavera added a comment -

fixed some issues that @lopex told me

Show
David Calavera added a comment - fixed some issues that @lopex told me
Hide
Thomas E Enebo added a comment -

Fixed in commit 6b1a6fd. I sort of hand merged this one for a couple of reasons:

1. Many jruby 1.8 and 1.9 methods were named with a 19 suffix. This looked strange in one case because there was a 1.8 method which in its method body called a 1.9 method. I did a decent sized renaming for this. I think it was easier doing this refactoring first rather than applying your patch and then refactoring.
2. All methods which are 1.9 methods should just be method19 and not method1_9. Perhaps that would have been a better convention than 19 but all our other methods are 19 now, so we should just keep doing the same thing for consistency. I don't think we should ever need a 18 method designator either, but circumstances may demand it in the future (not sure when though).

Good work...this ended up wiping 13 spec problems. Keep em coming David.

Show
Thomas E Enebo added a comment - Fixed in commit 6b1a6fd. I sort of hand merged this one for a couple of reasons: 1. Many jruby 1.8 and 1.9 methods were named with a 19 suffix. This looked strange in one case because there was a 1.8 method which in its method body called a 1.9 method. I did a decent sized renaming for this. I think it was easier doing this refactoring first rather than applying your patch and then refactoring. 2. All methods which are 1.9 methods should just be method19 and not method1_9. Perhaps that would have been a better convention than 19 but all our other methods are 19 now, so we should just keep doing the same thing for consistency. I don't think we should ever need a 18 method designator either, but circumstances may demand it in the future (not sure when though). Good work...this ended up wiping 13 spec problems. Keep em coming David.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: