Hey Naveen, I'm not familiar with Scala, so please correct me if I'm wrong with my assumptions. This basically sounds like we'd have an interface for the Scala API and a separate implementation, right?
In general, I really like these decoupled approaches (you already highlighted the advantages)! It would introduce a small overhead since we'd have to define the traits and implementation at two (different) locations, but it definitely increases clarity and separates concerns. I don't think we will have multiple implementations in future, but this might allow us to define the user-facing API in form of traits while allowing us to change the underlying "glue" as we want. My only slight concern is that this would introduce a bit more overhead since the documentation and API are defined somewhere else, but I have no experience with Scala, so I'll leave this up to the people who are more familiar with the topic. Best regards, Marco On Tue, May 1, 2018 at 11:48 PM, Naveen Swamy <[email protected]> wrote: > I think this project is going to significantly improve the usability of > MXNet-Scala APIs. > > I had a offline discussion with Qing about this. I agree with Yizhi that > keeping in the same namespace will make it easy for existing and new users > to quickly lookup the APIs. Along with that I have one recommendation, > first generate a trait for all the APIs and have the the instance in the > existing symbol. The usage would be something like below: > > trait SymbolAPIBase { > /** > api doc > */ > def Activation() > } > > object SymbolAPI extends SymbolAPIBase { > def Activation() > } > > object Symbol { > val api: SymbolBase = new SymbolAPI() > } > > Now users would use it as > Symbol.api.Activation() > > Creating a trait/Interface as several advantages: > 1) User do not have to know which concrete class to use, can be decided > later(Dependency Injection or Configuration driven application) > 2) Easier to change the implementation later without breaking the user code > -> You can insert different implementations through configuration using > frameworks such as Spring, etc., -> This is standard in most JVM driven > projects > 3) Easier to Unit test -> You can create Mocks easily using Mockito > 4) helps with multiple inheritance…you cannot inherit multiple classes > > Let me know what do you guys think. > > Thanks, Naveen > > On Sun, Apr 22, 2018 at 9:09 PM, YiZhi Liu <[email protected]> wrote: > > > I personally like the design here. Since we have seen technical > > difficulties of compatibility, I would like to ask people pay > > attention to the 'How to combine with existing APIs' section: > > https://cwiki.apache.org/confluence/display/MXNET/ > > MXNet+Scala+API+Usability+Improvement#MXNetScalaAPIUsabilityImprovement- > > HowtocombinewithexistingAPIs > > > > Qing proposed three options, > > > > 1. Add a new Class/Object called "NewSymbol/NDArray" with full > > implementation. > > 2. Create a new Class and change the name space for all of the > > functions (e.g Activation -> NewActivation) and let Symbol/NDArray > > extends that. > > 3. Create a new Class and override the Same functions with different > > implementations. > > > > If we have to choose from option 1 and 2, I would like to +0.5 for > > option 2, with which users can quickly aware of the new easy-to-use > > API: they type 'Symbol.' in IDE as usual and these functions pop up. > > > > 2018-04-19 10:58 GMT-07:00 Qing Lan <[email protected]>: > > > Hi All, > > > > > > I am Qing, one of the Scala API maintainer for MXNet. I would like to > > propose a new design on Scala APIs, it will be really helpful for user to > > use MXNet Symbol/NDArray. This is a follow-up from Naveen’s proposal. > > > > > > Background: > > > The current design on Scala would take arguments as key-value pair and > > didn’t provide the type information for different arguments. There are > > document missing for different functions which makes it even hard to use. > > > > > > Our approach: > > > We will provide a better designed Scala API for user to use with full > > documentation and arguments definition. All arguments will be > specifically > > targeted to different functions. Please see one example that we show in > the > > Wiki<https://cwiki.apache.org/confluence/display/MXNET/ > > MXNet+Scala+API+Usability+Improvement> and leave any thoughts you may > > have. This wiki includes examples, targets and scenarios we have so far. > > > > > > Thanks, > > > Qing > > > > > > > > -- > > Yizhi Liu > > DMLC member > > Amazon Web Services > > Vancouver, Canada > > >
