different behavior of stdlib ostruct vs. ostruct-gem
Open
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 175
- Forks
- 35
- Avg merge
- 16h 14m
- Merged PRs (30d)
- 1
Description
I am on Ruby 3.0
With stdlib ostruct I get:
irb(main):002:0> x = OpenStruct.new
=> #<OpenStruct>
irb(main):002:0> x.varname1 = 'varval 1'
=> "varval 1"
irb(main):003:0> x.to_h
=> {:varname1=>"varval 1"}
irb(main):004:0> x.varname1 = 'varval 2'
=> "varval 2"
irb(main):005:0> x.to_h
=> {:varname1=>"varval 2"}
irb(main):006:0> x.varname2 = 'varval 3'
=> "varval 3"
irb(main):007:0> x.to_h
=> {:varname1=>"varval 2", :varname2=>"varval 3"}
irb(main):008:0> x.varname2 = 'varval 4'
=> "varval 4"
irb(main):009:0> x.to_h
=> {:varname1=>"varval 2", :varname2=>"varval 4"}
Starting with version 0.5.0 of the ostruct-gem: I get:
irb(main):001:0> x = OpenStruct.new
=> #<OpenStruct>
irb(main):002:0> x.varname1 = 'varval 1'
=> "varval 1"
irb(main):003:0> x.to_h
=> {:varname1=>"varval 1"}
irb(main):004:0> x.varname1 = 'varval 2'
=> "varval 2"
irb(main):005:0> x.to_h
=> {:varname1=>"varval 1", false=>"varval 2"}
irb(main):006:0> x.varname2 = 'varval 3'
=> "varval 3"
irb(main):007:0> x.to_h
=> {:varname1=>"varval 1", false=>"varval 2", :varname2=>"varval 3"}
irb(main):008:0> x.varname2 = 'varval 4'
=> "varval 4"
irb(main):009:0> x.to_h
=> {:varname1=>"varval 1", false=>"varval 4", :varname2=>"varval 3"}
one of many side effects is:
irb(main):009:0> y = x.dup
/var/lib/gems/3.0.0/gems/ostruct-0.5.0/lib/ostruct.rb:304:in `[]=': undefined method `to_sym' for false:FalseClass (NoMethodError)
Did you mean? to_s
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in lib/ostruct.rb at the []= call reported at line 304, and reproduce the Ruby 3.0 behavior with ostruct 0.5.0 using the examples in the issue. Compare repeated assignments and dup with stdlib OpenStruct; done means updated assignments retain the expected symbol key and dup no longer raises the shown NoMethodError.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100