Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BulletinHeading should allow arbitrary combination of data type designators T1T2 #44

Open
petringo opened this issue May 17, 2019 · 1 comment
Assignees

Comments

@petringo
Copy link
Contributor

It is not uncommon within internal messaging to use arbitrary bulletin heading data type designators, that are intentionally unstandard to distinguish from standard data type designators used in external messaging.

The DataTypeDesignatorT1 enum should be made an interface like DataTypeDesignatorT2, renaming the enum e.g. StandardDataTypeDesignatorT1. Immutable classes for non-standard data type designators T1 and T2 (e.g. CustomDataTypeDesignatorT1 and CustomDataTypeDesignatorT2) should be created. Equality of objects should be specific to implementing class.

The parser should attempt to parse a standard data type designators, and if it fails to do so, then attempt to parse as non-standard data type designators. Combination of standard and non-standard T1 and T2 should not be prohibited, but if either of T1 or T2 is non-standard, the combination of T1 and T2 should be considered non-standard.

To avoid dependencies to different implementations in parsing (or serializing) code, relations between T1 and T2 could be represented within standard DataTypeDesignatorT1 and DataTypeDesignatorT2 objects.

@petringo
Copy link
Contributor Author

petringo commented Jun 6, 2019

I think it might be a good idea for DataTypeDesignatorT1 to have an abstract method

DataTypeDesignatorT2 t2FromCode(char code)

as each DataTypeDesignatorT1 implementation should know the concrete type of DataTypeDesignatorT2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants