As an application developer, I may need to manage one or more Option implementations as a collection, so that they may be reused across an application, instead of managing arrays of Option.
For example: Instead of managing and having to perform array manipulation on varargs of Option instances and / or using Option[], we should provide a public interface (and private implementation) called OptionsByType that allows representing collections of Option instances, arranged by the concrete implementation type.
Currently Bedrock internally uses the @Internal "Options" class to achieve this, but we should make this a public facility, through a clean interface, that of which the "Options" or any other class can implement.
While the Options class is used extensively, for the most part only internal implementations and unit/integration tests will be effected by this change. However there are several potentially used (but internal) interfaces / classes / methods that will be effected by this change; namely;
The Profile interface - which accidentally exposes and uses the Options class for call-back methods.
The Platform interface - which accidentally exposes the internal Options class for acquiring configured Option instances.
The Application interface - which accidentally exposes the internal Options class for acquiring configured Option instances.
The ApplicationListener interface - which accidentally exposes the internal Options class when raising events.
Each of these will be changed to use or return the new OptionsByType interface, thus protecting applications from future changes and exposure to the internal implementation classes.
As an application developer, I may need to manage one or more Option implementations as a collection, so that they may be reused across an application, instead of managing arrays of Option.
For example: Instead of managing and having to perform array manipulation on varargs of Option instances and / or using Option[], we should provide a public interface (and private implementation) called OptionsByType that allows representing collections of Option instances, arranged by the concrete implementation type.
Currently Bedrock internally uses the @Internal "Options" class to achieve this, but we should make this a public facility, through a clean interface, that of which the "Options" or any other class can implement.
While the Options class is used extensively, for the most part only internal implementations and unit/integration tests will be effected by this change. However there are several potentially used (but internal) interfaces / classes / methods that will be effected by this change; namely;
Each of these will be changed to use or return the new OptionsByType interface, thus protecting applications from future changes and exposure to the internal implementation classes.