> So how do i know if something is a corner case or not ? It’s a fair question, but I have a fair answer: ask clarifying questions! If i could give you one bit of advice (applicable beyond just this situation), it would be: “less certainty, more inquiry.” I spend a *lot* of time on these writeups, whose sole purpose is to enable productive discussion. To the extent the write-ups don’t make something clear, ask. There’s nothing wrong with saying “I don’t understand that …”
> Again, at least in my case, the problem is not if this direction is garbage > or not but that i don't fully understand the document you sent to us. That’s fine. But you use words that seem to imply “this direction is garbage.” You may not mean to, but you frequently use words like “wrong” or “that’s not what you want, what you want is…”, very early in the discussion, before you’ve even fully internalized what I’m proposing. When the document is solely about the direction, and you say “this is wrong”, you are saying the direction is wrong. I get that this isn’t how you mean it to come off, but it does. This may be a cultural thing; for example, in english, “impossible” means “contrary to the laws of physics”, and in French, my understanding is that it means “that would be inconvenient for me.” But Americans are offended by this, because when something is clearly possible (“can I wait at the table for my companion to arrive”) and we are told it is “impossible”, one feels like one is being told that up is down, or black is white. Again, the cure for this is “less certainty, more inquiry.” > Questions like what is the relationship between a deconstruction pattern and > a static pattern ? Is there several form of static patterns ? What a guard is > ? etc. > All these questions are important to understand the document you have sent. Yes. In some sense, that is what I thought the paper was about, so if those didn’t come through clearly, I didn’t do my job 100%, and you should ask clarifying questions until you get what I’m proposing. (Constructively and politely, of course.) At that point, you might agree or disagree or might feel that I skipped some parts, and then it makes sense to discuss those things. But, if I write a paper about the big picture, I would rather not move onto syntax or translation or performance until we at least are in sync on what big picture is being proposed, its pros and cons, and an understanding of where the picture gets fuzzy. For a topic as big as patterns, I have tried very hard to break things into chunks that are small enough to be discussed, but big enough to cover one area. The granularity varies, I wrote an as-large doc about exhaustiveness, which is surely a corner case (but a complex one.) But here, I am proposing an ambitious notion of pattern matching in Java, more so than Scala and C#, and I’d like people to understand what I’m trying to achieve before they start proposing alternatives fro various aspects (which may not fit into the bigger picture at all.) I don’t think I can break it down much further without losing sight of the goal.
