Hacker News Reader

Comment by tkot | Hacker News Reader

Could you list these features? I was under the impression that apart from some things that can be easily done in C# but are pretty much impossible to do in Java (like value types* and pointers) the languages were pretty similar.

Some C# things seemed rather strange (like delegates), some purely cosmetic (like indexers) and there were also things that Java had but C# did not like covariant return types (available from C# 9.0)

*Project Valhalla is supposed to bring it to Java but I wouldn't hold my breath waiting for it.

View on HN

The "dynamic" keyword [1] is my favorite blunder in C#. It's great if you are use it for COM interropt but it's awful otherwise.

The code compiles but from time to time it fails at runtime and performance are sometimes Ok, sometimes not depending on the call stack.

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

dynamic is amazing for the extremely niche use case of interop with dynamic languages. I had a system which executed Python scripts on devices using an orchestrator written in C#. With dynamic and IronPython, I could seamlessly unit test the whole enchilada without writing un-Pythonic Python or ugly C# wrappers.

Accessors come to mind:

    class Foo {
        int Bar { get; set }
    }

Allow you to get/set the value of someFoo.Bar as if it were a public member. If you want read- or write-only members, you just remove the "set" or "get" portion. If at some point you need to add logic to the setter, you just do

    int Bar { get; set { /* setter logic goes here */ } }

You still use assignment syntax ("someFoo.Bar = newValue"), but this syntax is desugared into a call to the setter method. Ditto for the getter.

IMHO they make class APIs much cleaner and forward-compatible (on the other hand, if you started with a public member and then need to add a proper setter with some logic, you would break the API).

Also, non-nullable types are a pretty nice way to avoid checking for null every other line of code.

And these are literally just the first couple examples that came to mind.

If you need a shortcut for accessors, you may aswell make your fields public and avoid get/set altogether...

Not if you need to implement some setter logic though, or want to reserve the option to do so in the future. And not if you want those instance variables to be available as JavaBean properties.

I haven't developed in Java in a long time, but public instance variables were a no-no when I did for these reasons.

This allows you to override the logic later. Public fields in a language where "x.y" means "directly access field y on value x" don't allow that; x.y forever means "directly access field x" and you can't later interpose code between attributes and the code accessing it.

This isn't the only way of doing it, depending on your language. Python has a completely different mechanism where a class can start with a directly-accessed "y", but in a later version make it a property. (More than one, actually.) Some languages route all property accesses through something you can hook. Some languages simply automatically do what C# is doing here.

Semantically and abstractly, there's no reason to every not be able to override a property access in later versions like that, because it is so darned useful. Unfortunately, performance wise, it's hard to beat a language that guarantees structure layout and guarantees that x.y can be compiled into a single constant memory load instruction, and unfortunately, you can't just wave "compiler optimization" at the problem and make it go away (considered in isolation this seems like an obvious solution but as usual as it starts interacting with all the other features it gets much harder than the simple cases). The higher performance languages have a strong reason to give people ways to get guaranteed direct struct member accesses.

Though please note that if you "upgrade" anything from a field to a property, you need to recompile any dependencies. Otherwise they will obviously try to invoke the field that no longer exists, instead of calling the property methods.

I think this is can be handled with Lombok using @Getter and @Setter annotations (https://projectlombok.org/features/GetterSetter). It is not exactly the same because you call generated methods instead using assignment syntax but I guess it's close enough - if you need some custom logic in the getter/setter then you remove the annotation and write your own implementation (I think Lombok might be smart enough to ignore the annotation if an appropriately named getter/setter is present).

Non-nullable types sound great, I wonder if this could be introduced to Java in a backwards-compatible way (I suppose it would follow the same path with introducing explicitly nullable types first, though I guess it could be handled using Optionals?).

Reply on news.ycombinator.com