<div dir="ltr">Hello to everyone on the mailing list. I would love to share some feedback with you regarding the Code Reflection API used to implement LINQ in java.<br><br>Unfortunately, I found myself in the situation where I don't have much time to work on a project and probably will not have it in the foreseeable future, so I will have to speak based on limited experience using the API. Firstly, I will talk about the problems I encountered, then mark some positive features and finish with general thoughts on the direction of the project and jdk in general.<br><br>The problems started earlier than expected, particularly on extending the Quotable interface. When I just built jdk from Babylon and created a new project, the quoted() method, to my surprise, has been throwing UnsupportedOperationException. I spent multiple hours trying to figure out whats wrong, unit finally I stumbled onto following rows in babylon repo:<br><br><span style="background-color:rgb(255,255,255)"><font color="#000000" face="arial, sans-serif">A subset of code in <code style="box-sizing:border-box;padding:0.2em 0.4em;margin:0px;border-radius:6px">java.base</code> is copied with package renaming into the <code style="box-sizing:border-box;padding:0.2em 0.4em;margin:0px;border-radius:6px">jdk.compiler</code> module.<br></font></span><br>This gave me a hint to add "requires jdk.compiler" to module-info, and it finally worked! I am not sure if this is how it intended to work, but if so, this topic could use more clarification.<br><br>Moving to API itself, there are a few points I would like to address. I would like to emphasize that I am speaking as a person that builds API to reach out from one high-level language to another, so my feedback is obviously biased. That said, I found an API containing too many low level details.I didn't even get to know what is dominatedBy and other methods related to this "domination". The difference between body and block is also not clear, I didn't find a case during work on a project where the body just had one block. <br><br>Naming could also use some improvement. Specifically, the uses() method, due to word meaning both that it uses something and that it is used by something is unclear to me. capturedValues() name also was really misleading to me, since it seems like it should return a map of values of expressions inside the OP, while it, as I understand, just includes some part underlying ops. It also is really similar to capturedValues() of LambdaOp which in fact contains captured values. AAnd just generally, having VarAccessOp to contain its captured value would be really helpful since it would spare from passing down Map of captured values through a long chain of methods.<br><br>I also did not find a particular use for the transform method. I initially thought it could be used to translate a tree into another language tree, but it instead transforms op into another op. I'm not sure if it replaces one node with another (which would make the tree mutable), or if it just produces a new one and then I don't really know what's the use of it.<br><br>Lastly, what was particularly strange is the fact that composite condition ops do not contain their operands and are not in their operands() method, but instead in bodies() method. Not sure if its intended, but for me it was extremely counterintuitive.<br><br><br>Now let's talk about positive sides. Generally, I really liked that API is (if all low-level methods are ignored), pretty simple yet powerful. I managed to get everything that I required using just a few simple methods like operands(), resolveTOHandle(), result() and other once situatively. By the way, talking about result(), I didn't find a case where it returns something other than Op.Result, and I guess for many op types result() return type could be narrowed.<br><br>I also found it really pleasant that Quotable is implemented by default, so I don't have to do any additional steps to start working with Quotable-extending interfaces. Though, it would be really helpful if java.util.function interfaces can become Quotable (unless there is a conversion between equivalent functional interfaces), so LINQ and other querying apis could become interchangeable with streams.<br><br><br>And lastly, a few thoughts about the general direction of Babylon development. I am obviously biased, but I found the API too low level. I would also argue that most of the use cases for java developers will interact with code reflection api would involve reaching out to other high-level languages, so it would make sense to make api a little more abstracted. Generally speaking, the jdk approach to "shoot in the middle" seems wrong to me. Generally, some particular use case takes up like 95% of demand for features. This is not particularly the case here, but accumulatively high-level languages would be, I guess, the most common target. Currently, on the other hand, API aims at middle-level languages (if those even exist), and lowering tree is used for low-level interactions. I would argue that non-lowered API should aim for high level languages, while lowered for low level. Middle-level models could be produced as a high level tree + some details from a lowered one.<br><br>That's all for now. I hope in future I could spare some more time and contribute something more than currently, maybe providing feedback also on API evolution. <br><br>PS: github repo if you are interested: <a href="https://github.com/Evemose/linq">https://github.com/Evemose/linq</a><br><br><br></div>