JavaLaurence Posted March 16, 2013 at 10:30 AM Posted March 16, 2013 at 10:30 AM It would be more elegant/future-proof/flexible to remove most extension-related APIs from the BrickMaster, and move these to separate Extension APIs. In Java, you could have the following in BrickMaster List<Extension> getExtensions(); And you could have new classes like public class WifiExtension implements Extension {..} public class RS485Extension implements Extension {..} This refactoring would clean up the BrickMaster API to reflect more of its essence. Quote
borg Posted March 17, 2013 at 09:18 PM Posted March 17, 2013 at 09:18 PM Yes, i agree. We had this discussion already quite often. It would be possible to generate something like this. It was once even planned during the protocol V1 to protocol V2 transition. But we decided to not invest time in this for the moment, since must of our users configure their Extensions in the Brick Viewer and don't need the API anyway. There is a huge list of TODOs and new products and so on, we have to pick our battles wisely . Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.