Replies: 2 comments 1 reply
-
Java doesn't know an Personally, I prefer code that is explicit. Makes understanding it easier. The only downside I've seen so far is that you cannot just omit a parameter that cannot be I'm not totally against switching to |
Beta Was this translation helpful? Give feedback.
-
First of all, thanks for the extensive reply 👍 Your right, it is more explicit. But I think that like other java-ports it doesn't use language features such as undefined properly and by default null is preferred when undefined would better match the intent. I also don't think it makes sense to just replace all null's with undefined, it would need to be checked on a case by case basis where undefined would better match. Having said that, everything works perfectly fine with null but it was just something that sprung to mind while using antlr4ng. But I'm glad your not totally against it, when I get time I'll make some more concrete (and small) proposals and we can discuss if those make sense :) |
Beta Was this translation helpful? Give feedback.
-
I noticed that both the original antlr4 js runtime as well as antlt4ng use
null
instead ofundefined
to return nothing everywhere. Working with javascript (and typescript) for sometime it feels somewhat unnatural in the context of these languages.It also causes small inconveniences when using atnlr4ng, for example when you implement a Visitor you always need to explicitly return null. With undefined you could just not write the
return
statement and it would implicitly returnundefined
. There is more occasions where I find my self writingXXX ?? undefined
to change null into undefined but it does feel strange that it's required considering the vast majority of TS and JS code prefers undefined over null.Any change in this would be a breaking change but I was wondering if it is something you would be considering for a major-release?
Beta Was this translation helpful? Give feedback.
All reactions