You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, MslObject and MslArray accept MslEncodable instances but hold onto them as objects of their original concrete type. However this can create a problem because when someone tries to parse a MslObject or MslArray, they are expecting a MslEncodable to be parsed out and returned as a MslObject, not as an instance of the original concrete type.
The current code pushes this problem out to the caller which is why certain MslEncodable classes encode or encode+decode their MslObject or encoded byte[] representations before returning them. There are corresponding FIXME comments. The right solution, although it comes with higher computational overhead, is probably to add a .putMslEncodable() function that must be used for MslEncodables, and reject MslEncodable values from the .put() function.
The text was updated successfully, but these errors were encountered:
At the moment, MslObject and MslArray accept MslEncodable instances but hold onto them as objects of their original concrete type. However this can create a problem because when someone tries to parse a MslObject or MslArray, they are expecting a MslEncodable to be parsed out and returned as a MslObject, not as an instance of the original concrete type.
The current code pushes this problem out to the caller which is why certain MslEncodable classes encode or encode+decode their MslObject or encoded byte[] representations before returning them. There are corresponding FIXME comments. The right solution, although it comes with higher computational overhead, is probably to add a .putMslEncodable() function that must be used for MslEncodables, and reject MslEncodable values from the .put() function.
The text was updated successfully, but these errors were encountered: