<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello John,</div><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">>
Thank you for the well-written note, and for sharing your results. <br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Anytime. I remember watching a video that included Brian Goetz/Ron Pressler. They mentioned that the most useful and helpful form of feedback we could provide the Java Team is a run through of us using the preview features in a non-trivial project, and noting our experiences with it.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> Good comment.<br></div><div class="gmail_default" style="font-family:monospace">> <br></div><div class="gmail_default" style="font-family:monospace">> This feels like it <em>might</em> be a simple oversight.
If so we might choose to fix it. Or it might well be a conscious
decision to limit the impact of reflection on the language proper. The
sharpening of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">String.class</code> to <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">Class<String></code>
actually requires complicated moves in the heart of the language, the
JLS; such moves are very expensive. Addressing this one would require
JLS surgery</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for the context. I definitely didn't realize the potential cost of making that cast. It makes a lot more sense why they might have avoided doing it. Also good to know about the Java Language Specification. I definitely see what you mean now.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">>
Sometimes inconvenient stuff like this, like the no-go for generic enums
JEP 301, is due to highly technical roadblocks which are too hard to
remove.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">That's definitely fair. Admittedly, I was coming from a place of annoyance when I was talking about the cast and also JEP 301. I need to be more mindful of the level of complexity and collaboration involved for problems like that.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">>
Good summary of a tricky design problem. The images of “islands” is
good. We are also talking about a functor between categories, for those
who find such ideas illuminating.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I just looked up functors, and I'm having a lot of fun with the concepts behind it. Here's one example from Wikipedia.</div><div class="gmail_default" style="font-family:monospace"></div><div class="gmail_default" style="font-family:monospace">
<p>> "Let <i>C</i> and <i>D</i> be <a title="Category (mathematics)">categories</a>. A <b>functor</b> <i>F</i> from <i>C</i> to <i>D</i> is a mapping that associates each object <span class="gmail-mwe-math-element"><span class="gmail-mwe-math-mathml-inline gmail-mwe-math-mathml-a11y" style="display:none"></span><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/68baa052181f707c662844a465bfeeb135e82bab" class="gmail-mwe-math-fallback-image-inline" aria-hidden="true" style="vertical-align: -0.338ex; width: 1.98ex; height: 2.176ex;" alt="X"></span> in <i>C</i> to an object <span class="gmail-mwe-math-element"><span class="gmail-mwe-math-mathml-inline gmail-mwe-math-mathml-a11y" style="display:none"></span><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/00816772e8dff4e6733c478ec77fab0382264a93" class="gmail-mwe-math-fallback-image-inline" aria-hidden="true" style="vertical-align: -0.838ex; width: 5.53ex; height: 2.843ex;" alt="F(X)"></span> in <i>D"</i></p><div>On paper, it seems basic and simple, but as a language feature between 2 separate categories of language citizens, that is earth-shattering. It's also hilarious because that is exactly what I tried to create through reflection.</div><div><br></div><div>I tried to create a Map where each key is one of the permitted subclasses, and each value is the respective constructor for the permitted subclass. I had to complicate the Map a bit because of implementation details, but according to the definition above, I think I made a functor. I will have to read up on it more.</div><div><br></div><div>>
One thing I would try: Attach grammar fragments or regexps-with-groups
to each record using annotations. Then build a tool which uses those
annotations to weave a bridge between the islands. It would require
some sort of grammar generator. I’d look for a combinator-based
library, I think. I don’t work in this area enough to know what’s
current. But I admire some Lua-based experiments <a href="https://github.com/vsbenas/parser-gen" style="color:rgb(57,131,196)" target="_blank">1</a>
and think it’s likely some Java programmer has adapted those ideas to
Java and lambdas and records etc. If not maybe it’s time to do so</div><div><br></div><div>I'll give it a shot. I don't know about any grammar generator libraries, but one other person on this thread mentioned something similar that they built, so I am sure I'll find something.</div><div><br></div><div>Thank you again for your help and insight!</div><div>David Alayachew<br>
</div></div></div></div>