Channels
#stdlib
- u
uli
10/12/2017, 10:22 AM@demonwav Short ping to get you in the loop ^^^^ - u
uli
10/12/2017, 10:57 AMsorry, forgot to rename the project. here is the new URL: https://github.com/uluckas/s2s-KotlinAutoClose - d
demonwav
10/12/2017, 2:04 PMYeah I guess the project name is pretty bad - d
demonwav
10/12/2017, 2:05 PMJust sorta threw a name on it without thinking - d
demonwav
10/12/2017, 2:06 PMI'm glad there's discussion about this though, last time I brought it up all I got was a bunch of people saying it's not necessary, which baffles me - u
uli
10/12/2017, 2:40 PMHi @demonwav, du you care to comment on the simple scooping approach? Sure it does not solve your issue #3 (extra try catch), but do you see other drawbacks? - d
demonwav
10/12/2017, 2:47 PMI firmly believe the only real solution is for Jetbrains to get off their high horse and add it as a feature of the language natively, which is what the whole exercise was trying to show to begin with - d
demonwav
10/12/2017, 2:47 PMYours looks less fluent, but safer than my solution - d
demonwav
10/12/2017, 2:48 PMIt also has the benefit of inheriting multi-catch whenever it gets added to the language - d
demonwav
10/12/2017, 2:49 PMYours also looks less likely to break in future releases (what happens when Jetbrains decides functions can't have keyword names in the future?) - d
demonwav
10/12/2017, 2:51 PM"Absolutely agree. But we want to avoid language construct just for this as much as possible" it ridiculous and
makes excellent points on why a stdlib approach will always fall shortalexd457 - u
uli
10/12/2017, 2:54 PM@demonwav thanks for breaking the ground for that topic. Hope it moves on either direction. - d
demonwav
10/12/2017, 2:55 PMWhenever I talk with my Java friends about Kotlin, when Kotlin's lack of
comes up, every time without fail, they react with disbelieftry-with-resources - e
evanchooly
10/12/2017, 2:55 PMyou mean
?.use { } - d
demonwav
10/12/2017, 2:56 PM
is not a legitimate replacement for.use { }
, as indicated by the above conversation, and the linked conversations thereintry-with-resources - e
evanchooly
10/12/2017, 2:56 PMoooh. all legal talky. - d
demonwav
10/12/2017, 3:00 PM@karelpeeters renamed the project https://github.com/DemonWav/kotlin-try-with-resources👍 2 - u
uli
10/12/2017, 3:08 PMLet's get back to the topic of this channel. - u
uli
10/12/2017, 3:10 PMIs JB interested to provide any more advanced implementation of Closeable-management then
as part of stdlib?Closeable.use { } - m
marcinmoskala
10/12/2017, 3:12 PM@uli What do you mean? You mean Java 9 solution? - u
uli
10/12/2017, 3:13 PM@marcinmoskala When you scroll up, we discussed a scope base solution to resolve some of the issues of kotlin's missing try-with-ressource - u
uli
10/12/2017, 3:15 PMI would donate my code from s2s-KotlinAutoClose to stdlib, improve it according to reviews or be completely happy if JB said, they come up with their own solution. - u
uli
10/12/2017, 3:16 PMOh, and if they rather introduce language support - great 🙂 - k
karelpeeters
10/12/2017, 3:43 PMYes your solution - while it's the best we have atm - still feels hacky and doesn't belong in the stdlib in this form. - d
demonwav
10/12/2017, 3:44 PMI'm unconvinced the stdlib is capable of properly handling this problem in any form - d
demonwav
10/12/2017, 3:44 PMThis isn't really a library problem - d
demonwav
10/12/2017, 3:44 PMmore of a language problem - u
uli
10/12/2017, 3:57 PM@karelpeeters care to elaborate? What is missing that you would expect from a non-hacky solution? - d
demonwav
10/12/2017, 3:59 PMAs long as the implementation is allocating a collection of closables and/or throwables, it's a hacky solution - d
demonwav
10/12/2017, 3:59 PMAnd the only way you could accomplish it without a collection would be with some kind of preprocessor code generator (ew) or a language construct like java