Grouping class members by accesibility?

1

As much as I enjoy Kotlin (and Java), one thing that really irks me is that I keep having to write “private” whenever I’m adding a new private members to a class. In C++, all the private members are “grouped” under a “private” declarator in the class header:

class MyCppClass
{

private:
  int member1, member2, member3;

public:
  int pMember1, pMember2;
}

And this makes a lot of sense to me. “Private members go here, public members go here”. For enhanced readibility, I shouldn’t be mixing them togheter. And because of this system, I’m not doing that by default.

So I would love to see a feature in Kotlin to declare all private members in one place, and all the public members in another.

class MyKotlinClass (

    val pMember1: Int,
    val pMember2: Int,

  private:
    val member1: Int,
    val member2: Int
) {}

Just a thought

1 Like
2

In C++ the necessity of the grouping came mostly from the preprocessor. There seem to be no reason to do it that way in Java/Kotlin.

In my personal opinion, if you having so many constructor parameters that you need to split them in groups, you are doing something wrong. We had a discussion about it some time ago, but without any clear winner.

If you are talking not about constructor parameters, but about class level declarations, you can easily group them yourself or using IDE code rearrange feature.

3

Agreed, keep number of parameters to a minimum. But that’s kinda missing my point.

I’m talking about both constructor parameters (i.e. class members in Kotlin, no?) and class members (fields and functions). Example:

class MyKotlinClass (

    val pMember1: Int,
    val pMember2: Int,

  private:
    val member1: Int,
    val member2: Int
) {

    fun myPublicFunction1() {}
    fun myPublicFunction2() {}

  private:
    fun myPrivateFunction1() {}
    fun myPrivateFunction2() {}
}
4

The first part in round brackets are constructor parameters. As for the second part, I can’t see how it is better than:

// public declarations
    fun myPublicFunction1() {}
    fun myPublicFunction2() {}

//private declarations
    private fun myPrivateFunction1() {}
    private fun myPrivateFunction2() {}

If you want something closer to C++ headers, than you probably separate all public calls into an interface.

5

It probably just boils down personal preference, based on what you and I are used to. A matter of taste, if you will.

With two private functions, having to write “private” for each doesn’t seem very verbose. But what about 10 private functions? Or 15?

I respectfully disagree that this

fun myPublicFunction1() {}
fun myPublicFunction2() {}

private:
  fun myPrivateFunction1() {}
  fun myPrivateFunction2() {}
  fun myPrivateFunction3() {}
  fun myPrivateFunction4() {}
  fun myPrivateFunction5() {}
  fun myPrivateFunction6() {}
  fun myPrivateFunction7() {}
  fun myPrivateFunction8() {}
  fun myPrivateFunction9() {}

isn’t better than this

fun myPublicFunction1() {}
fun myPublicFunction2() {}

private fun myPrivateFunction1() {}
private fun myPrivateFunction2() {}
private fun myPrivateFunction3() {}
private fun myPrivateFunction4() {}
private fun myPrivateFunction5() {}
private fun myPrivateFunction6() {}
private fun myPrivateFunction7() {}
private fun myPrivateFunction8() {}
private fun myPrivateFunction9() {}
6

Although it looks neater when your member functions have neither parameters nor body, I don’t think this is necessarily so when they do at least have a body.

Also, when reading the code, your eyes need to scroll up to the last access label to see whether it’s private, public or whatever and you also need to decide how the access label and the functions themselves should be indented relative to the rest of the code.

In C++, of course, the implementation of the member function is usually outside the class itself - the latter only contains the header - so these considerations are not much of a problem.