Thanks for your insightful reply!

Properties can be a good alternative to a method-heavy API with many parameters.

It’s interesting, because I never even considered this usecase.

Imho the whole design feels more like a workaround for the lack of named arguments and default parameters.

I would design the API completely differently for multiple reasons:

• No overloading. Overloading simply does not exist, so it would not have been an alternative to start with.
• No mutability. It creates questions, especially for this API, which I don’t even care to answer for users. E. g. you add caching of results – now the user changes some properties – which result will be returned?

Trying to keep as close as possible to your sketch, here is how I would design the API:

class PersonFindOptions(
  let firstName: Option[String] = None,
  let middleName: Option[String] = None,
  let lastName: Option[String] = None,
  let userName: Option[String] = None,
  let emailAddess: Option[String] = None,
  let title: Option[String] = None,
  let office: Option[String] = None,
  let department: Option[String] = None)
  
module PersonFinder {  
  fun find(options: PersonFindOptions): Set[Person] = ...  
}

// usage:
PersonFinder.find(PersonFindOptions(firstName = Some("Joe"))

Though I would also consider using a normal method with default parameters instead:

PersonFinder.find(firstName = Some("Joe"))

I would probably only define that PersonFindOptions class, if I also had other options (like PetOptions) I wanted to keep separated.

Drag-and-drop GUI builders like WinForms and WPF.

I would design the API to take all required and immutable arguments in the constructor. Only settings that can actually be mutated after-the-fact may receive a setter, whose name clearly indicates it mutates something.

Allowing experimentation and code completion-driven development.

Again, I would not expose mutable properties in the first place – I expect that the instance is completely initialized after calling the constructor, and everything necessary to do this needs to go into the constructor (or a factory method that in turn calls the constructor).

In the end, I think everything that’s useful about properties can be done without them, if the language is designed for that from the beginning. Some requirements:

1. All members (fields, variables, methods) live in the same namespace.
2. Parameterless methods can be defined and called without the ().

This in turn gives rise to APIs where the implementation details (“is ‘property’ x simply forwarding to a field, or doing some computation?”) are isolated from the callers.

All of that, while retaining this crucial bit of information (stored value vs. computed result) for users reading the code (by giving value access and method access different colors in the IDE).

Here is my favorite example:

class Person(let fullName: String) {
  fun firstName: String = fullName.split(" ").get(0)
  fun lastName: String = fullName.split(" ").get(1)
}

A user would use such an instance like this:

let somePerson = ...
println(somePerson.firstName)
println(somePerson.lastName)
println(somePerson.fullName)

Now I decide that the way I compute first and last name from the full name is a bit silly, users should simply pass first and last name instead!

Therefore, I change the class to this:

class Person(let firstName: String, let lastName: String) {
  fun fullName: String = firstName + " " + lastName
}

… and the user code requires no change at all, because whether a member is a method (fun) or a field (let) does not impact source (or binary) compatibility – it’s the IDE that shows the difference with different colors.

This approach also means that this information is often times the first time available for users to see, because older languages basically wrapped all fields in getters (Java) or properties (C#), making all accesses look the same, and therefore discarding this important bit of information.

That’s a really nice design!

That’s my point. A tuple literal is a collection literal.