11–20 of 54 posts
What I would love to come over from C# is: * Auto-Properties - Get rid of all those ugle getters and setters cluttering up POJOs * Object and Collection Initialisers - https://msdn.microsoft.com/en-us/library/bb384062.aspx
might want to checkout lombok. https://projectlombok.org/
What I would love to come over from C# is: * Auto-Properties - Get rid of all those ugle getters and setters cluttering up POJOs * Object and Collection Initialisers - https://msdn.microsoft.com/en-us/library/bb384062.aspx
might want to checkout lombok. https://projectlombok.org/
I've been bitten by the "Long indices for arrays" lack once before. But then again, I had no reason for storing a String of length greater than MAX_INT in memory in the first place. Streaming it was the better approach in my case. Honest question: is there ever an acceptable case for having such a long String in memory?
Run-time visible generics are pretty important because it lets us avoid boxing everything. In .NET, they don't have this problem, and as a result primitive dictionaries are ~17x faster [0]. Java folk wisdom seems pretty accurate to me in this case.
> The issue of primitive specialisation of generics is only tangentially related to type erasure, and run-time visible generics are actually much less useful than Java folk wisdom insists. Run-time visible generics are pretty important because it lets us avoid boxing everything. In .NET, they don't have this problem, and as a result primitive dictionaries are ~17x faster [0]. Java folk wisdom seems pretty accurate to…
Interestingly, specialization can be done at compile-time and doesn't necessarily have to be a runtime feature. Here's a Scala compiler plugin doing that: http://scala-miniboxing.org/
I've been bitten by the "Long indices for arrays" lack once before. But then again, I had no reason for storing a String of length greater than MAX_INT in memory in the first place. Streaming it was the better approach in my case. Honest question: is there ever an acceptable case for having such a long String in memory?
So would this affect all flat memory allocation? Say if you wanted to allocate 100GB for a bloom filter, would you need to break it into chunks?
> The issue of primitive specialisation of generics is only tangentially related to type erasure, and run-time visible generics are actually much less useful than Java folk wisdom insists. Run-time visible generics are pretty important because it lets us avoid boxing everything. In .NET, they don't have this problem, and as a result primitive dictionaries are ~17x faster [0]. Java folk wisdom seems pretty accurate to…
He's talking about reification versus specialization. The .NET runtime is specializing generics for value types and that's how you avoid boxing. For normal classes though, specialization would not have any benefit and the boxing argument goes away. Interestingly, specialization can be done at compile-time and doesn't necessarily have to be a runtime feature. Here's a Scala compiler plugin doing that: http://scala-min…
It's neither according to the usual (C++-inherited) lingo where specialisation is the userland override of generics reification. Refinement may be a better term for what the article is talking about (runtime-optimised instances without reified types).
And refinements should already be doable in java today with no static type information, Pypy does it with list strategies, I expect Objective-C's hidden classes could also enable it (though I'm not aware of such a use).
> Interestingly, specialization can be done at compile-time
That's where they started...
What I would love to come over from C# is: * Auto-Properties - Get rid of all those ugle getters and setters cluttering up POJOs * Object and Collection Initialisers - https://msdn.microsoft.com/en-us/library/bb384062.aspx
What I would love to come over from C# is: * Auto-Properties - Get rid of all those ugle getters and setters cluttering up POJOs * Object and Collection Initialisers - https://msdn.microsoft.com/en-us/library/bb384062.aspx
If there's no logic in the getter and setters, just make the properties public.
Unless someone else can help me, I think this is really bad advice for a C# developer.