TomNewChao commented on PR #2656:
URL: https://github.com/apache/plc4x/pull/2656#issuecomment-5091169853

   > Wow ... quite a bit happened here during my few days off :-)
   > 
   > So one thing I wanted to point out: Even if in Java several external 
dependencies existed for various things (such as BitBuffers etc), I still 
rewrote everything from scratch in SPI3. One the one side, this way I could 
build a perfect fit for PLC4X, but also I thought this would be a perfect 
template for porting to other languages as there is no need to fins a "suitable 
but mostly not 100% replacement".
   > 
   > Another thing I noticed: We currently rely on the plc4x build-tools maven 
plugin to generate code. In my commercial offering I decided to give something 
else a try: I built an mspec parser and code-generator that fits the target 
language (in that case Rust) ... possibly it might be worth investigating the 
options to use a pure dotnet code generation tool ... the antlr4 grammar for 
mspec should help a lot with that. In the end a pure dotnet toolchain would 
eliminate the dependency on Java for dotnet developers while still being able 
to call the build from the overall maven reactor.
   > 
   > I think the API diverged quite a bit since it was created several years 
ago, but i think I saw you already picked up some of these changes.
   > 
   > If you need any help ...don't hesitate pinging me. I can also invite you 
in the plc4x slack channel, if you want more instant feedback (during sensible 
EU times ;-) )
   
   Thanks for the pointers — the code generation one lands on the open question 
in the description, and with an option I hadn't considered.
   
   The bit buffers were the same call in miniature: I dropped Ayx.BitIO and 
wrote the reader/writer rather than hunting for a closer package. That you 
rewrote that layer in SPI3 for the same reason is useful — I'll take SPI3 as 
the reference to follow rather than a source to copy line by line, and say so 
where .NET pushes a different shape.
   
   On a pure .NET toolchain: agreed, and for the reason you give. Removing the 
Java dependency for .NET developers is worth more than finishing the freemarker 
templates. I had a look at the antlr4 grammar and the parser side does look 
straightforward — the work sits above it, in the type model.
   
   Slack sounds like the right place for the rest — yes please, and thanks for 
the offer. I'm on UTC+8, so your working day runs from my afternoon into my 
evening; that lands inside sensible hours on both ends.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to