JavaLaurence Geschrieben March 16, 2013 at 10:30 Geschrieben March 16, 2013 at 10:30 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. Zitieren
borg Geschrieben March 17, 2013 at 21:18 Geschrieben March 17, 2013 at 21:18 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 . Zitieren
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.