3 ms·
> Probably not a good idea since they break encapsulation by exposing internals of the class. And thousands of manual get/set functions don't? Thousands of li
by troupo 18d ago
> Probably not a good idea since they break encapsulation by exposing internals of the class.
And thousands of manual get/set functions don't?
Thousands of lines of builders don't?
Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers https://learn.microsoft.com/en-us/dotnet/csharp/programming-...
> for the simple reason that there is no simpler syntax than plain old synchronous code.
But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and...
Java always opts out for "let the developer handle all the complexity all the time even for the simplest most used parts of the code".
- gf000 18d ago> And thousands of manual get/set functions don't? By definition, they don't. They are verbose and hard to maintain, but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you. > But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and... No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds
- troupo 18d ago> but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you. So do properties in C# which object initialization relies on. With significantly less manual code, or the need for tedious builder chains and withers. `{ prop = x }` is no more encapsulation breaking than ` .setProp(x) `, but actually makes developer experience better. > No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds What's Java's equivalent of x = await someFunction() await waitForSomeOtherFunction()
- gf000 18d agoIf the two calls are sequential then simply: var x = someFunction() someOtherFunction() If you would have written var xTask = SomeFunctionAsync(); await WaitForSomeOtherFunctionAsync(); string x = await xTask; then it would be: try (var scope = StructuredTaskScope.open()) { // JDK 24+ preview feature var x = scope.fork(() -> someFunction()); scope.fork(() -> waitForSomeOtherFunction()); scope.join(); String result = x.get(); // already completed }
- troupo 18d agoawait implies async functions. Looks like Java's "there is no simpler syntax than plain old synchronous code" is just a lot of extra manual wrangling of stuff
- gf000 18d agoAnd the first two lines are an async function as they are, without any special handling. They won't block the thread, and you can have millions of them. Like it's no accident that c# with their goldfish attention span wanted to ship virtual threads as well next to all their millions of features.
- samus 18d ago> And thousands of manual get/set functions don't? My statement doesn't apply to mere data carrier classes. Anyway, getters and setters are an antipattern as well since one can just as well make all the fields public. > Thousands of lines of builders don't? With withers most of these will go away. And a class will be able to choose which things can be set, which is not the case for initializers. > But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and.. That code won't look that much different with async/await.
- troupo 18d ago> Anyway, getters and setters are an antipattern as well since one can just as well make all the fields public. I Java? Yes. Because of the language design, and not because of some inherent "encapsulation" or something. Somehow `x with { a = b }` doesn't break encapsulation and offers nice DX. But object initializers? Lol > And a class will be able to choose which things can be set, which is not the case for initializers. The class in C# can easily chose what can and cannot be set. Because unlike Java it actually cares about things like this. Quick example class Test { public int x { get; set; } public int y { get; } } var t = new Test{ x = 1, y = 2 }; I can give you a hint: this will not compile. Another example: public class Matrix { private double[,] storage = new double[3, 3]; public double this[int row, int column] { // The embedded array will throw out of range exceptions as appropriate. get { return storage[row, column]; } set { storage[row, column] = value; } } } var identity = new Matrix { [0, 0] = 1.0, [0, 1] = 0.0, [0, 2] = 0.0, [1, 0] = 0.0, [1, 1] = 1.0, [1, 2] = 0.0, [2, 0] = 0.0, [2, 1] = 0.0, [2, 2] = 1.0, }; Incomprehensible abilities for Java-land > That code won't look that much different with async/await. Lol. https://news.ycombinator.com/item?id=49726868 https://news.ycombinator.com/item?id=49726868
- samus 16d agoYou can go with a lot less code if you don't care about proper cleanup of resources.