if that looks useful at all, i can push it to maven central.

the gains are probably limited but it was simple enough to cobble together.

and, as a side note, might be the first project I've ever gotten to 100% test coverage. 😄

manhattan project? 🤔

@evanchooly When you have 100%, it's time to try something for real men: mutation testing!

Why did you hide all the functions inside object instead of making them top-level functions?

Why the decision to make them functions, instead of properties? Especially in the case of properties that you can also set this seems quite counter intuitive.

Because

System.setProperty

returns previous value and you cannot do that with Kotlin properties.

also, those properties are mutable and the fields wouldn't reflect that.

i was thinking of playing backing properties blah blah blah but that's literally just an hour or two of playing around.

@User uploaded a file: Untitled and commented: it could look like this as a field

But this way you lose returned value of

setProperty

.

true. i’m not sure that’s a bad thing. how many people actually use that return value?

Yeah, I think the best solution would be a standard property, and then another

fun getAndSetFileSeparator(value: String)

to accompany that.

@evanchooly You did in tests 😉

i did because it was there 😉

I kinda prefer to the property to the function but it’s honestly 2 char difference.

hm yeah, I prefer the properties personally. I didn't even know what

setProperty

returns, and I think using that value hurts readability when you could just use the property's getter before setting it if you really want the previous value

that’s been my impression as well.

Some premature-optimization-fans wouldn't agree 😉

that’s why you have to cut them off early

also if you want to avoid duplication, maybe you could extract this logic out into a delegated property

private fun systemProperty(key: String) = object : ReadWriteProperty<Any, String?> {
    override fun setValue(...) { System.setProperty(key, value) }
    override fun getValue(...) = System.getProperty(key)
}

then all of the properties could be, for example:

val classPath by systemProperty("java.class.path")

doesn't affect external use of the library but makes it a bit cleaner for you, arguably, since you can hide all the getProperty/setProperty in that delegate?

and you can use that ReadWriteProperty both for the read-only and the read-write ones, you'd just set the property to a var or a val depending on which you want

Very good idea. I often forget how powerful using delegation might be in removing boilerplate.

premature optimization fans can roll their own 😉 I personally think using properties for something that even Java calls a

System.{get|set}Property

is straightforward and readable

Some of properties which are known to be provided by every JVM implementation might be made non-nullable

@kevinmost i’ll update to that today.

the

val

is weird given the set there.

does the set just get ignored for the

val

fields? vs the

userDir

property, e.g., that is mutable