Is there something that’s like… the opposite of `@...

# javascript

[ankushg]

Is there something that’s like… the opposite of @JsExport? Like a @JsHide?

If I have a class in a KMP project that has a public suspend fun that’s intentionally public for non-JS platforms. That class also has several other valid-for-export methods (including a callback-based API for said suspend fun), but because of that single coroutine, I can’t currently mark the class as @JsExport

I’d love to be able to tell the compiler to export everything except that pesky suspend fun

Is my only option right now to suppress the warning? It looks like the compiler just drops a comment into the generated .d.ts file, but it would be nice to tell it that I don’t want to export that method at all

[Matthias Geisler]

Actually that sounds more a problem of abstraction than a compiler problem (I know not helpful). However if you use expect/actual you only define the methods which are really mutual over all sourcesets plus those which are platform specific - BUT it can hunt you in terms of common code (e.g. you still want to be able to call this method from common).

[Matthias Geisler]

Also - I think you are tinkering with a JS and Native project right now, right? - Please consider that the concurrency are fundamentally different (as also the Kotlin docs describes it with hierarchical source structures), so that is might be the reason for your actual problem.

[andylamax]

I don't think this is a problem of abstraction at all. Why? coz the compiler is already doing all of this for the jvm with @JvmSynthetic You can author a class and mark certain methods to not be available for the Jvm.

If the team saw an importance of it in the Jvm, It is also important in the Js World. Something like a @JsSynthetic would definitely suffice.

And just to be feature complete, and introduction of @NativeSythentic for hiding native exports, would be a grate fit

[Matthias Geisler]

Easier said than done, I suppose. While @JvmSynthetic has a direct correspondent in Java, Js or Native don't have such things. In certain cases visibility modifiers might suffice (or even remove them entirely), but in terms of suspending functions it won't, since you have no equivalent and a transformation in something which is compatible with the target platform is not trivial. Otherwise projects like NativeCoroutines would not exist, I believe.

[andylamax]

What we are trying to question here is this, why is @JvmSynthetic available for Jvm and there is no Js and Native equivalent?? Coz @JvmSynthetic works so well for suspending functions (and other usecases) in the Jvm, it should also work for Js and Native.

[Matthias Geisler]

I think you do not get entirely my point here - Java has this capability build-in, while JS or C or Objective-C have not. So while for Java it is more or less easy to have such thing, for other platforms it is certainly not. So you need to think about how to emulate such a behaviour, while not compromising shared sources like common...and here it gets super complex...

[andylamax]

I get your point. But I still think it can be done. It is not the first time the kotlin compiler does this (bring capability) in other platforms (like js) that do not have the said capabilities.

e.g. Js doesn't have a concept of private members (until recently). But the kotlin compiler would mangle that away. and provide somewhat a solution that would be not full proof for obvious reasons, but something that is sufficient withough compromising common code.

Something similar can be done for Js with and equivalent of @JvmSythentic .
If I were to be on the kotlin compiler team, this annotation would ask the compiler to turn off the warning of the exported file to js, mangle it up like a non exported member and more over, inhibit the typescript definition of the said file.

As an active user of kotlin/js. This would be extremely sufficient for us. I can't say much about native as my experience is lacking in that department

[Matthias Geisler]

I am not saying it is impossible...but it must be very very carefully thought through and it is not trivial to implement.

If I recall it correctly private methods are there for ages (at least before 2018) with the leading '_' or with scopeing in JS.
Sometimes it feels actually the opposite for me when I do JS in Kotlin...like the missing Promise#allSetteled method or the decision to go for mocha instead of jest. But I wont complain...Jetbrains did a awesome Job.

As I said it must be very very carefully thought through - for the old compiler it would be certainly impossible since you lose a chunk of code you might need for common (since it uses js directly) or you introduce a very nasty workaround. For the klib format - I have no idea how its structure is, but here it might be possible to propagate things until it is compiled into actual JS. However here I am just guessing...

But you can completely avoid that if you simply respect the chain of shared sources in KMP. For example you can define an Interface in common, which contains only methods which are usable for all platform...then you define a concurrent sourceset with a second interface which extends the interface from common and adds then methods which are available for concurrent platforms and so on. JS makes the same, since it is the only non concurrent platform and no Annotation is needed. And it brings me back to my initial statement - "problem of abstraction".