I’m probably alone in this, but… I keep running in...
# announcements
r
I’m probably alone in this, but… I keep running into situations where I want to take an anonymous object (with properties on it, natch) and then add new fields to it, creating a /new/ anonymous object with all the same fields but one or two more things on it.
It seems like something that could be supported with some kind of anonymous delegation? but certainly doesn’t seem supported now
current workarounds tend to be - make the original object implement an interface and then delegate to it, or manually redefine the properties, etc. They are annoying, as they add a lot of extra ceremony that won’t be used elsewhere.
conceptually what I want is pretty much auto-delegation of all properties on the anonymous type. 🤷‍♂️
Just thought I’d throw this out into the ether in case others feel the same way 😅
z
sounds like you want a
Map
😛
r
lol if maps remembered the individual type of each key and enforced it at the compiler level without a lot of extra ceremony… yes!
z
I think there are a few implementations of such a map in popular Kotlin libraries –
CoroutineContext
is one, Compose’s Ambients is kind of another – they enforce key/value types match but not presence (i.e. compiler enforces that
map[stringKey]
returns a
String
, but not that that’s only a valid call after
map[stringKey] =
)
r
yeah, I would do something like that if it was mechanically necessary and I felt it was less cumbersome then the current workarounds. But my use case is more of an everyday thing that would ideally still give me all of the nice kotlin compiler protections I’m accustomed to
I think at the root, I just want a way to say “make this new object provide the full public interface of this “object reference” by delegation, without having to provide a typename
the current delegation system comes so close for allowing this, but skids out by requiring a formal interface definition via typename
@Zach Klippenstein (he/him) [MOD] thanks for the thoughts though 🙂 plenty to ponder
z
Another approach would be using a Proxy if you’re only concerned about the JVM, but then you’re completely out of the compiler realm. Maybe typeclasses, ala #C5UPMM0A0?
r
yeah i wonder if I could find a way to make typeclass techniques brief enough to be competitive here. 🤔 All part of my quest for more expressive brevity without sacrificing safety. I may just be talking myself into submitting a request if a similar one doesn’t already exist
(<3 arrow, always)
Somehow I got this far into the thread without mentioning the most obvious workaround - referencing the original object on the new anonymous object. That works ‘fine’, and should be considered the simplicity bound… I’m wishing for sugar to make that cleaner. But what I really want is to be able to reference the contents of both objects via a unified reference. Small? Somewhat trivial? Yes. I imagine it would work sort of like situations where ‘this’ can bind to a few different things (happens a lot when putting extension functions inside class scopes, for example)
m
lol if maps remembered the individual type of each key and enforced it at the compiler level without a lot of extra ceremony… yes!
maybe what you’re looking for is the Typesafe Heterogenous Container data structure or better the
SymbolMap
structure (described in the same article). It was originally described by Brian Goetz in Effective Java, but it’s easy to port it to Kotlin, I did it once as an afternoon project.
r
@Matteo Mirk Good read, thanks
🏅 1
👍 1