Cool (I think!) little trick @Sam showed me: https://blog.lidalia.org.uk/2023/02/maps-with-typed-keys-in-kotlin.html

interesting, but why

properties.apply { put(prop.name, initialValue) }

instead of the way easier to read

properties.put(prop.name, initialValue)

??

The property delegate provider also has to return the map, because the map is what's actually being used as the property delegate.

ah, i overlooked that! probably because the return type of

property

is implicit 😆

Relatedly the compiler can't prove that the properties have a subtype; in this class

class Props : AbstractPropertyMap<Any>() {
  val anInt by property(1)
}

anInt

has compile time type

Any

. I couldn't find a way to make its type defined by the type of the argument to

property

.

Oh, nicely spotted! The property delegate provider always uses the

Map<String, V>

as the property delegate, meaning the property type is always just

V

, never a subtype. Not very useful if

V

is

Any

. I think it can be improved like this, though:

abstract class AbstractPropertyMap<V>(
    private val properties: MutableMap<String, V> = mutableMapOf()
) : Map<String, V> by properties {
    protected fun <V2: V> property(initialValue: V2) =
        PropertyDelegateProvider<Any, ReadOnlyProperty<Any, V2>> { _, prop ->
            properties[prop.name] = initialValue
            ReadOnlyProperty(properties::getValue)
        }
}

Nice, that meets all my disappointments! I will update the post...

Uhm, reminds me of the Heterogeneous Type Safe Container pattern, later evolved to SymbolMap, but with much more boilerplate. https://stevewedig.com/2014/08/28/type-safe-heterogenous-containers-in-java/

I may not be understanding; which do you feel has more boilerplate?

At first I'd say your solution, since the THC/SymbolMap has a very short implementation, don't know if you're familiar with it or read the article. Anyway, I apologise in advance if I may have misunderstood what your solution accomplishes. If I got it right, yours will enable a class to act both as a Map and have typed properties delegated to it, with related checks. While a SymbolMap sure has less features, but is actually a map and lets you store and retrieve values in a type-safe way, that is:

get(Symbol<T>): T
put(Symbol<T>, T): Unit

The solution we came up with looks like this:

class Foo: AbstractPropertyMap<Any>() {
  val prop1 by property("value1")
  val prop2 by property(21)
}

The two things seem to have different goals to me; SymbolMap is about having a

Map<Symbol<Any>, Any>

where you can be sure you put and retrieve a specific type.

AbstractPropertyMap

is about having something which is both a

Map<String, T>

and an object such that the fields on the object are also entries in the Map with the same name and value.

Watch out: SymbolMap doesn't work blindly for Any but for T, meaning it can store and retrieve different types in a safe way 🙂 But Yeah, I get that AbstractPropertyMap does more, that is providing object properties. You're right, to use a SymbolMap you need to pass around a symbol (which is immutable, constant or not), and you don't have compile time properties, but the trade-off is that it's both a dynamic and type-safe structure, while an AbstractPropertyMap derivate obviously has to declare its properties. Apologies again, I misunderstood the features of your solution, but it was a good discussion nonetheless.