-
Bug
-
Resolution: Unresolved
-
Medium
-
None
Bits type mapping is completely nonsensical where String mapping is concerned. On the one hand we have:
@Override public String toString() { final var helper = MoreObjects.toStringHelper(Foo.class); CodeHelpers.appendValue(helper, "_one", _one); CodeHelpers.appendValue(helper, "_bar", _bar); return helper.toString(); }
and on the other hand we only have:
public static Foo getDefaultInstance(final String defaultValue) { List<String> properties = Lists.newArrayList("bar", "one" ); if (!properties.contains(defaultValue)) { throw new IllegalArgumentException("invalid default parameter"); } int i = 0; return new Foo( properties.get(i++).equals(defaultValue) ? Boolean.TRUE : null, properties.get(i++).equals(defaultValue) ? Boolean.TRUE : null ); }
i.e. there is method producing the output 'getDefaultInstance' expects. Furthermore the only it works is single-bits – otherwise 'defaultValue' is just not included in the List and there is just now way to specify more than one bit that would get accepted by getDefaultInstance().
Replace 'getDefaultInstance(String)' with a valueOf(String) method which will accept a comma-separated list of Strings identifying individual bits. This is guaranteed to be okay because of how bit argument is defined which in turn goes to identifier, which in turn goes into ABNF, which does not allow for commas.
Also define a counterpart stringValue() matching the formatting, which is part of (the proposed) BitsTypeObjectContract. The contract here is that the output of stringValue() is accepted by ofValue(String).
Both of these methods need to be specified by BitsTypeObject.
- is blocked by
-
MDSAL-743 Add BitsTypeObject
- Resolved