You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mxnet.apache.org by GitBox <gi...@apache.org> on 2018/10/12 06:48:37 UTC

[GitHub] yzhliu edited a comment on issue #12772: [MXNET-984] Add Java NDArray and introduce Java Operator Builder class

yzhliu edited a comment on issue #12772: [MXNET-984] Add Java NDArray and introduce Java Operator Builder class
URL: https://github.com/apache/incubator-mxnet/pull/12772#issuecomment-429219340
 
 
   IMO it is not always "bad" to expose Scala classes. Scala classes are not necessary a "new language" that requires users to learn. e.g., scala.Tuple, many Java 3rd parties (Guava, Apache Common, javatuples) provide exactly the same thing.
   
   Spark only re-implement a very small set of classes, mostly RDDs, and not every RDD have a Java version.
   
   At least these four classes are already "java-friendly". Duplicating will only increase maintenance efforts. Honestly I don't see why `DataDesc` is not java-friendly.
   
   It makes sense to me to have Java version of NDArray, (and maybe also Module, etc), because they have too many functions that are not java-friendly. But not every class is in such situation.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services