https://kotlinlang.org
Join Slack
<@UGP48AGDC> I looked this up one time and pretty certain this feature is still in proposal phase. ...
# announcements
j
@bbaldino I looked this up one time and pretty certain this feature is still in proposal phase. I agree that it would be incredibly useful. I can't find a reference at the moment, but Kotlin language proposals are found here .
b
Ah bummer. Thanks for the reference, I'll see if I can find it there.
n
I feel like this has the possibility to break existing code, no?
suppose the author of Foo is doing import SomePackage.*
i guess it's unlikely actually
Well.... but if you allow this, do you allow it generically?
j
Knowing KEEP there are 10 pages of discussion over four years
n
If you do, then you can definitely break code in weird and surprising ways. If not, then it would be weird and surprising you can't be generic over this.
n
this would be a lot easier if Java/Kotlin supported partial classes a la C# 🙂
n
I dunno I remember kinda wanting this or something similar when I first started learning about these things and then eventually kinda deciding it was too much.
Well, you'd still depend on the author of Foo to define his class partial, which they don't really have much reason to do randomly
n
that's true
b
I wanted to use this in situation where I have a method taking a receiver of 
Foo
, so I can effectively add support for taking a new type (and providing a compatibly-typed result).
Is there any other places other than receiver functions where these sorts of extensions are even useful? (Or inside the class itself, I guess). I'd think that alone probably isn't too common.
Not that that would make it acceptable for language support, I guess.
n
well, these sort of things like you said, they are either implementation conveniences, or they are part of a sort "DSL" type thing
typically Foo will have member functions taking receiver lambdas, and within that lambdas you have a bit of a DSL where you suddenly use some extension on strings
b
Right
n
viewed that way, you're kind of trying to extend Foo's DSL to new types, without Foo being aware. It's a bit dangerous.
mostly once you bring generics into it
b
Well I still have to maintain the "contract" (or else it would fail to compile). The code using the new type would be in my new code, not the original lib.
n
yeah, in the use case you have envisioned
b
Yeah, in my case "Foo" does have a generic type
n
in the general language case though
it doesn't have to go that way
it could change the meaning of existing code, that uses the module that defines the new Foo.T.extension
b
But how would that existing code resolve to see the new extension? It wouldn't be imported.
n
module A uses Foo, defines this new extension function, module B uses A and Foo
does an import *
now suddenly code that B wrote that used Foo with no regard for anything in A could change meaning
b
Hm. I'd think many existing things could break if code is doing a massive wildcard import.
n
I'm not saying this is the end of the world, just saying for a language designer who has to consider every edge case there's a lot of pitfalls
b
Yeah, that's fair.
n
yeah it would need to be a wildcard import
b
But I wonder if that problem is so "big" it falls into "not going to worry about solving it" territory.
n
Maybe it would be cleaner to do this by inheriting from Foo?
or delegating it?
that seems more correct, not sure if its possible
b
It wouldn't work for my case, as there's a helper defined in the lib where 
Foo
is defined that creates the 
Foo
instance to "kick off" the dsl, basically. So the using lib would have to rewrite that as well.
n
what if you had
Copy code
class MyExtensions(private val foo: Foo) {
    fun String.someOtherStringExtension() { /* use foo maybe */ }
}
and used that
and invoke it like
Copy code
with(MyExtensions(this /* Foo */)){
b
If I'm understanding that right, I think it could work but would make the DSL less ergonomic to use
n
can't win 'em all
b
Indeed 😛
I worked around this ok, but was curious when I bumped into it. It would've been nice to have.
n
I don't think I follow
You would simply use your own helper, that would call the other helper
I guess though the question is whether Foo has an interface, or if it's an open class
if you have neither of those then, again, it's tricky 🙂
b
Right, but in my case I'd rather not do that, it would change the flow of that call flow in a surprising way when reading code. Maybe a minor thing, but in my case I don't think it's worth it.
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by