Hacker News Reader

Comment by kjksf | Hacker News Reader

I would phrase it like that: most languages (C++/Java/.NET) have unhealthy obsession with creating unnecessary setters/getters, paying for it with increased compile time, code bloat, slower code.

In Java/C# land refactoring tools even give one-click access to "create me some setters/getters".

This is not to say that abstracting access with functions has no place, but if all they do is get/set the value, they are unnecessary.

View on HN

C# and Python (for examples) don't use getters and setters, they use properties which provide the same interface as direct access variables when the need arises for more complexity, client code doesn't need to know about it. Languages without this feature needs to make everything getter/setter if they don't want to break the API when something needs additional logic.

Python does have properties, which work via decorators @property (which decorates a getter) and @foo.setter.

He literally just said that

And indeed Go code has its fair share of (otherwise) unnecessary getters because of this.

So, let's suppose you don't create getters or setters, because all that function does is get/set the value.

Six months later, you discover that you, in fact, do need to do something besides getting/setting the value.

If you created a getter/setter, you could just change its code. If you, instead, had raw access to the field, you now need to update every single instance of client code that called your getter/setter.

Most of the time, your compiler/VM can optimize the getter/setter call away, and a bunch of trivial get/set logic isn't exactly the worst source of cognitive overhead.

There are infinite possible futures but only one now.

Write the best possible code needed today. Anything else is premature abstraction.

I do get the "what if" temptation, I just think it should be actively resisted.

See [YAGNI](http://wiki.c2.com/?YouArentGonnaNeedIt).

A helpful (to me) metaphor is that you're paying for an option. (In the finance sense, not the type system sense.) Sometimes it's worth buying an option, sometimes it's not, but don't think it's free.

A more simple analogy: it's an insurance.

It's certainly wise to subscribe an insurance for your house, but for every single drinking glass you own...?

If it's a tea set you inherited from your great-grand-mother, when you break it the insurance won't un-break it. If your property suddenly needs to be more than a property, chances are that this change will break the LSP or trigger a larger redesign anyway.

This not one of those instances though. The cost of having getters/setters is essentially zero, the potential downside can be big.

Ok, reality time: out of all the getters/setters you've ever written, how many of them have you ever needed to modify? And for those modifications, how long would it have been to refactor your code base to go from public field access to publi method access ?

> paying for it with increased compile time, code bloat, slower code.

Auto-properties in C# are one line of code, same as fields, and the getter/setter methods should always be inlined which turn them into field accesses anyway. So I'm not sure how that would affect compile times or lead to slower code in anything but some pathological use case. Or DEBUG, but at that point all performance bets are off.

(Technically Microsoft can get worse performance on properties vs. fields when using NGen - that's why they have TargetedPatchingOptOutAttribute - but that doesn't apply to regular, non-Framework assemblies.)

As for code bloat `public int SomeValue { get; private set; } = 6;` encapsulates a publically read-only/privately mutable property with a default value quite concisely...

(smacks forehead)

Wait, wait, since when can you put the default assignment right there on the same line? Go ahead, say since always... I dare you.

Edit: Apparently this came in C# 6.0 (July, 2015). Ok, now I don't feel so bad. :-)

On a separate note, C# might not sexy or even that popular, but I really enjoy coding in it, and the continuing evolution of the syntax is a joy.

It really is a joy to program in. I fought it off for the longest time (I like regular ole C, python, dabbled in Java long ago), but finally dipped my toes in and tried C# a month ago... While the language as a whole is a bit verbose, LINQ is incredible, and the breadth of the standard library is awesome.

Instead of a field, you get a field and two methods. It's more IL, more metadata, etc. Maybe when the JIT is all done it's eliminated, but it'll cost more to JIT.

Though I doubt this makes a ton of real world impact, performance wise. Stripping names would do more to shrink the .Net code.

> Instead of a field, you get a field and two methods

And if you wanted a publically read-only/privately mutable value without properties you'd have to write ... a field and one method. Possibly two methods if you wanted some shared validation code everywhere you assign the field.

Like I said, in practice, it's the same. If you have some case where three vs. two members makes a difference you're in pathological case territory.

Souns like get/set in swift for me. Does it have computed properties too?

    public double Area
    {
        get { return Width * Height; }

        set
        {
            Width = Math.Sqrt(value);
            Height = Width;
        }
    }

You can also use expression bodied members (that's the => syntax) with get/set. There's a shorthand if you only need to define the getter (i.e. read-only):

    public double Area => Width * Height;

Swift has the same syntax too except the last line.

Have they introducted willSet and didSet too?

Neat stuff, i may try the language out in a future project on windows.

There's no direct equivalent to willSet or didSet. The closest equivalent (aside from adding code before/after your own get/set code) might be INotifyPropertyChanged [1]/INotifyPropertyChanging [2]? But they are more for external observers and add a lot of boilerplate to your code. It's possible to manage the boilerplate, however [3].

[1] https://msdn.microsoft.com/en-us/library/system.componentmod...

[2] https://msdn.microsoft.com/en-us/library/system.componentmod...

[3] https://github.com/Fody/PropertyChanged

Reply on news.ycombinator.com