201–210 of 216 posts
Earlier quoted context omitted.
Not that nice compared to kotlin: data class Animal(dog: String, numberOfLegs: Int) val dog = Animal( name = "dog", numberOfLegs = 4 ) The amount of boilerplate for AutoValue builders is so ridiculous that most people use IDE plugins to generate it.
Nope, we just add @AutoBuilder https://github.com/h908714124/auto-builder
Earlier quoted context omitted.
This isn't true. For structs you can use 'this = ...' to overwrite yourself (including readonly fields) and reflection lets you set them too. fwiw those are both gross but I've run into both in production code (not written by me, naturally)
The same can be said for setters and getters with a backing field, you can access them through reflection. I can't remember how it works for properties with implicit backing fields but I thought they could be set via reflection as well?
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
> obfuscating what happens when you actually access them This is the point, AFAICT. In languages with both primitive "read/write field" operations that can't be interceded upon, but also with interfaces/protocols, "obfuscating" (encapsulating) a field access in getter/setter methods is how you allow for alternative implementations of the interface/protocol. Specifying your object's interface in terms of getters/sette…
> But in a language like Java, where field access has its own semantics divorced from function calls, you need getters/setters to achieve a similar effect. I think the problem with Java's approach wasn't just in allowing primitive slot access, it was in making that access be simpler and use less boilerplate than accessor access, so people are tempted to use it where it isn't really what they specifically want, and ac…
By saying that you have an accessor x, you're writing a method called x. Actually two: x and (setf x).
You can write auxiliary methods for these: with :around, :before and :after methods you can intercept the accessor calls to do "reactive" kinds of things.
... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
The pattern evolved from early Java’s lack of reflection. In order to give tools the ability to set/get data, we got the JavaBean. The culture internalized the pattern, and we’ve been mindlessly doing it ever since.
It definitely is the case that reflection in the JDK would be a very slow and ungainly way to do data access so I can see the 'bean' convention being a way around that.
Earlier quoted context omitted.
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?
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 contextu…
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`
Earlier quoted context omitted.
Appeal to authority. Show me a language with little to no patterns.
I don't think there is a language without patterns. But in other programming languages (Lisp, Haskell), we just call them functions. Edit: Actually, I think your request is even more ridiculous. If what Norvig is saying is true, then every language has patterns, because every language has bugs. So you are asking to substantiate his statement by providing a counterexample.
It's Pattern => Language bug, not Language bug => Pattern. You are assuming the opposite meaning.
In other words, not all bugs are patterns but all patterns are necesarily bugs (not IMO, it's just the interpretation).
... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
If you have a temperature class with a celsius field and change the internal representation to kelvin you have to update all client code to call a conversion method. C#s syntax sugar allows you to slot in the conversion method without a breaking change but it screws with the cost model of field accessing when used unresponsibly. Java doesn't have it so you would have to hide everything behind getters if you don't wan…
Earlier quoted context omitted.
If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). If you want to specialise object arrays to primitive arrays for efficiency, then I do not see why this cannot be a compiler optimization, since the types are statically known at the use sites. Perhaps Java interoperability is the reason for the choices Scala…
> If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). I'd argue it is, because the semantics of an array are the same whatever that array contains. In any case, there's no nice alternatives: a lot of Java APIs use Arrays, so not being able to work with them would be unpleasant, while having contexts in which y…
Earlier quoted context omitted.
I don't think there is a language without patterns. But in other programming languages (Lisp, Haskell), we just call them functions. Edit: Actually, I think your request is even more ridiculous. If what Norvig is saying is true, then every language has patterns, because every language has bugs. So you are asking to substantiate his statement by providing a counterexample.
About your edit, It's Pattern => Language bug, not Language bug => Pattern. You are assuming the opposite meaning. In other words, not all bugs are patterns but all patterns are necesarily bugs (not IMO, it's just the interpretation).
Anyway, what I really meant was that every language has semantic limitations that can manifest as patterns which the users have to apply. Even Lisp (static type checking) or Haskell (dependent types).