Hi Thanks for investing time to try the build and give your feedback (FYI I use Visual Studio Community 2017)
In fact my first approach until now was more 'bottom-up', now I've started from the 'Top down' perpective by trying to port Json unit test and thus its connector and thus precisely QueryPostProcessDataContext. Of course there is a lot of commented out code as I wanted just to run even just a part of the JsonDataContextTest unit test. The 'comment out' is helpful to progress and always have a codebase without compile errors. ATM, I've started porting FileHelper (which raises by itself lots of issues on IO nuts and and bolts within the Java vs C# mindsets, like Streams and Readers/Writers) and yes there is a lot of porting issues which are raised by Java perpective only and vice versa >From a bird eye point of view, I have the feeling that C# is now beyond Java in terms of VM based OOP languages (especially with .Net Core). I think I have also more fluency in C# than Java, which is maybe a bias in my understanding of Java core concepts. I fully agree with your remark that at this point a Design refactoring is necessary to go further (my work is more at the code level and thus embracing much less even missing crucial points of AMM paradigms) In the hope that my 'bud' raised enough motivation to start an AMM subproject like you suggested previously Best Regards Michel Kern Le 16 juil. 2017 5:22 AM, "Kasper Sørensen" <[email protected]> a écrit : > I notice that there is not yet a port of QueryPostprocessDataContext, which > is IMO critical to implement any connector. I think having that class (and > it's dependencies, for instance MetaModelHelper) ported is key for us to > push ahead with the rest of the details. As such I feel like many of the > interfaces that are there now can be easily be manually replicated and > maybe in some cases re-thought a bit for .NET, as well as for the fact that > there is no backwards compatibility concern in this port. > > Interfaces like Func, Action and Ref are certainly not needed in .NET, and > we should not include it. They're only there in the Java version for > backwards compatibility to the pre-Java 8 days. > > 2017-07-15 10:40 GMT-07:00 Kasper Sørensen <[email protected] > >: > > > OK so I can tell you this much: I succesfully built the project with > > "dotnet restore" and "dotnet build". Great work, I see there's a lot of > > code in here :-) > > > > Right now it doesn't contain any working DataContext implementations, > > right? It would be kinda cool to have at least one so that we can start > > building unit tests and stuff like that. I'll probably get back to you > with > > a PR for some small project structure things so that we have a place to > add > > unit tests, a way to add more modules and so on. > > > > I haven't done an in-depth review of the code, but for me the most > > important thing is that there is something we can iterate on and the > tests > > and such are instrumental in doing that. > > > > > > 2017-07-09 12:45 GMT-07:00 Michel Kern <[email protected]>: > > > >> Hello > >> > >> I've just published a "bud" of porting Apache MM from Java to C# (.Net > >> Core) > >> It's there: https://github.com/Echopraxium/apache_metamodel_ > dotnet_core_ > >> bud > >> > >> It is a limited subset (40 of the java source code files) but at least > it > >> compiles without errors and > >> uses .Net Core as suggested by Jasper. > >> > >> Please find below a copy of the attached README: > >> ************************************************************ > >> **************************** > >> Foreword > >> ------------------------------ > >> Here is a 'bud' version for a port of Apache MetaModel from Java to C# > >> (.Net Core). Please > >> notice that it is a very limited subset which has neen ported ATM. > >> > >> Conversion Issues > >> ------------------------------ > >> Even with a limited subset of the java source code files (40), I've > >> encountered a lot of > >> conversions issues, from the very straightforward (e.g. 'String s = > >> input_string.trim()' > >> becomes 'string s = input_string.Trim()'), to the ""equivalence > >> required"" (e.g. anonymous > >> implementation of interface, like in getComparable() method of > >> BooleanComparator class). > >> > >> Anyway, I've tried to do my best (even if my choices may reveal > erroneous > >> or even absurd), > >> at least to compile the 'conversion recipes' that I've crafted on the > way > >> (they are > >> documented in doc/java2csharp_recipes.txt). > >> > >> I've also provided a set of 'Helper classes' (under > >> apache_metamodel_dotnet_core/org/ > >> apache/metamodel/j2cs), like class extensions (e.g. add a GetHashcode() > >> method to the > >> C# 'object' class), type replacement (e.g. Java's Number class converted > >> to 'CsNumber') > >> , etc.. > >> > >> Here is the result of my 'J2Cs' (Java To C#) adventures until now. In > the > >> hope that it may > >> bring interest for validation and maybe a "child project" Apache > >> MetaModel which is a great > >> and innovative solution for interoperability in the Biotop of Data > >> Stores, well beyond the > >> ODBC and ORM solutions IMHO. > >> > >> Best Regards > >> Michel Kern (echopraxium on GitHub) > >> > >> > >> > >> > > >
