3 ms·
Not exactly true, but true for this use case. The new module keyword in Java 9 is only a keyword in module-info.java. You can still have a variable named module
by cakeface 9y ago
Not exactly true, but true for this use case. The new module keyword in Java 9 is only a keyword in module-info.java. You can still have a variable named module in regular class files. They wouldn't be able to pull this syntax trick with data as a keyword though.
- dtech 9y agoWhy not? `data class X` is currently invalid code. What is the problem with allow the `data` keyword in a class definition and not forbidding it in other contexts?
- chrisseaton 9y agoThat's just not the rest of the Java grammar is designed. It would be an unwelcome edge case.
- cakeface 9y agoMy first thought is that maybe there is an issue with inner class definitions here. Not sure how you'd define an inner data class but I'm guessing it would be similar to regular classes. If I have a `public class data` already in my codebase and then I have places where I declare a `data variable1` I think that there is potential for issues. I don't have much experience with grammars but I feel like the more contextual the parsing rule the more likely there will be nasty edge cases.
- dtech 9y agoI have experience with grammars, but not with the Java one. There isn't an inherent restriction on context-free grammars why this couldn't happen. In pseudocode this could work fine: classDef = accessModifier? classModifier* `class` identifier `{` (fieldDef|methodDef|classDef)* `}` fieldDef = accessModifier? fieldModifier* type identifier `=` expression classModifier = `data` fieldModifier = `synchronized` | `final` | `volatile` As you can see there isn't an inherent reason why the identifier rule should exclude the `data` keyword for this to work