Hacker News Reader

Hacker News

Comment by nikolay | Hacker News Reader

Parent Full thread

nikolay

Why underscores in "__data"? Is this just a temporary thing?

View on HN

It's decoy to avoid bikeshedding. The value class proposal used __value

When you say decoy, do you mean it's intentionally gross to keep people from going off on syntax debates?

I hope so!

Probably to avoid making 'data' a reserved word and breaking a ton of code that used 'data' as a variable name. Prior to Java 5, 'enum' was a very popular variable name too.

I'm having a difficult time trying to think of a case where "data" is the best variable name for anything.

Plus, it's 2017! There are so many tools to do a semantic search and replace and replace all variables, parameters, etc. called "data" with, let's say, "__data__". Why uglify the language instead of providing a migration tool like Python's 2to3?!

Java reserved words are reserved in all contexts. You can't have a variable called "class" because class is a reserved word. If 'data' becomes a reserved word, imagine the code that would no longer compile...

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.

Why 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?

That's just not the rest of the Java grammar is designed. It would be an unwelcome edge case.

My 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.

I 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

I agree, I hope that doesn’t end up being final.

Otherwise I really like this proposal. I absolutely love the ability to do D structuring, and I like the idea that they’re going to make it possible to make these immutable as well.

Reply on news.ycombinator.com