41 ms·

+1 for "insane". I'm honestly baffled by all this context nonsense in Scala, React and now Kotlin. Twenty years ago, Spring (among others) showed us how to do

+1 for "insane". I'm honestly baffled by all this context nonsense in Scala, React and now Kotlin. Twenty years ago, Spring (among others) showed us how to do proper wiring of separate elements in a clean way. Everything was simple and crystal clear (if a bit verbose). Programming became mostly additive (rather than multiplicative) in complexity and programs could easily be broken down to pieces easy to understand and implement. And now we are back pass parameters to functions off-band like in the times of VB6? Seriously!? Get off my lawn...

ohgodplsno 4y ago
Off-band is a bit of a misnomer. The cases where you end up with enough context to actually be able to call these functions are either "oh god what the fuck are you doing" or "you nested with/applys on purpose". It doesn't magically conjure parameters out of thin air. It's an extension of receiver functions, where, if before you had a function that took A, B and C as dependencies, the best you could write was A.doThing(b: B, c: C, paramIActuallyNeed: Int), or wrap everything in a class (which goes against what Kotlin is trying to do). In addition, there are some actual interesting things to do with it! It's ultimately syntax sugar to hide external dependencies. If tomorrow all your calls to Int.add(other) need to all be logged to database, I'd rather add context(DatabaseWriter) and have all the benefits of it (including compilation errors), rather than polluting my function signature. It's not like Context providers in React or in Compose, where you just call and assume it's in scope and it crashes at runtime if it's not: context providers will not let you compile unless it is certain they are in scope. Traditional dependency injection is still very much done and the standard in Kotlin, except without the pile of crap that is declaring beans in XML

ohgodplsno 4y ago

Off-band is a bit of a misnomer. The cases where you end up with enough context to actually be able to call these functions are either "oh god what the fuck are you doing" or "you nested with/applys on purpose". It doesn't magically conjure parameters out of thin air. It's an extension of receiver functions, where, if before you had a function that took A, B and C as dependencies, the best you could write was A.doThing(b: B, c: C, paramIActuallyNeed: Int), or wrap everything in a class (which goes against what Kotlin is trying to do). In addition, there are some actual interesting things to do with it! It's ultimately syntax sugar to hide external dependencies. If tomorrow all your calls to Int.add(other) need to all be logged to database, I'd rather add context(DatabaseWriter) and have all the benefits of it (including compilation errors), rather than polluting my function signature. It's not like Context providers in React or in Compose, where you just call and assume it's in scope and it crashes at runtime if it's not: context providers will not let you compile unless it is certain they are in scope. Traditional dependency injection is still very much done and the standard in Kotlin, except without the pile of crap that is declaring beans in XML