Looks like another issue with Data subclasses losing their fields. Probably need to look into a different way of forcing the shape, like just using normal instance variables and allowing the regular shaping logic to work.
Background: Data was designed at first to specialize all fields immediately. I forget my justification for doing that versus just letting normal shaping pick up the fields, but it may be due to them not really existing as instance variables. Existing logic for attribute accessors most likely confirms they are @ variables.
In net-imap, several data types are defined as subclasses of subclasses of Data:
https://github.com/ruby/net-imap/blob/66fad03b65e6589f70f092b3b697ca04815814da/lib/net/imap/command_data.rb#L170-L186
At least those subclassing the CommandData class appear to be losing writes to their data field, resulting in a majority of failures running the net-imap test suite.
See discussion here: ruby/net-imap#720
cc @nevans
Looks like another issue with Data subclasses losing their fields. Probably need to look into a different way of forcing the shape, like just using normal instance variables and allowing the regular shaping logic to work.
Background: Data was designed at first to specialize all fields immediately. I forget my justification for doing that versus just letting normal shaping pick up the fields, but it may be due to them not really existing as instance variables. Existing logic for attribute accessors most likely confirms they are
@variables.In net-imap, several data types are defined as subclasses of subclasses of Data:
https://github.com/ruby/net-imap/blob/66fad03b65e6589f70f092b3b697ca04815814da/lib/net/imap/command_data.rb#L170-L186
At least those subclassing the
CommandDataclass appear to be losing writes to theirdatafield, resulting in a majority of failures running the net-imap test suite.See discussion here: ruby/net-imap#720
cc @nevans