What name do you find more readable for a method t...

# codereview

[CLOVIS]

What name do you find more readable for a method that converts some external data into a Kotlin type?

val doc: Document = …

doc.read<String>()
doc.decode<String>()
doc.deserialize<String>()
// ?

what name feels the more natural to you?

[Joffrey]

I would only use read when there is some I/O or streaming involved. Otherwise, pretty similar. I would be biased towards decode when I implement the decoding by hand, or when it's about decoding types that are more like primitives. But that's not really an objective decision

[CLOVIS]

Document is a class that contains a ByteArray , so no IO or anything.

Another option was .parse() but to me that implies text-like contents, but this is just a binary blob.

[Paulo Cereda]

I like using .from<String>() or .to<Foo>(). 😉

[ephemient]

for comparison,
Java nio.Buffer uses get*() naming
Java SAX uses next*() naming
okio uses read*() naming

[Andrew O'Hara]

I like decode personally. Or to throw my own suggestion into the ring from http4k-format: asA

[Klitos Kyriacou]

Another comparison: Jackson ObjectMapper uses readValue<>() .

[Matthew Feinberg]

Would calling doc.read<String>() twice return the same date or different data? In other words, is it reading the entire contents of doc at once, or does it read one thing of the appropriate type and then advance some internal offset/pointer/state?

If it reads things one at a time (so multiple calls return different things) then I'd consider calling the class something different (For example, DocumentReader ) an then using .read or .decodeNext or deserializeNext or something.

If it just reads the entire thing at once (no internal state besides the ByteArray) then maybe something like .convertTo<String> or .to<String> or decodeAs<String> or something (to indicate that it's the whole thing). There may be a name inflict on .to though because of the infix to used for Pair construction.

To me, it doesn't matter as much whether the source is a stream or is entirely in memory, but rather whether repeated calls return the same value or different values (such as by advancing internal state). Generally, I'd look at standard library functions with similar behavior.

For example, I think that .decode functions in the standard library are generally used as constructors (so they are on a companion object) and for converting the entire content of something, we see functions like .toInt() etc, and for reading things sequentially, there are the stream APIs, so I think looking to those and naming things such that people who know a few standard library functions can guess the behavior...

[CLOVIS]

Would calling doc.read<String>() twice return the same date or different data?

In my case, it would return the exact same data each time, there is no internal mutation, so all the nextXXX variants are off.

[CLOVIS]

I think .toXX() isn't a good idea in my case because:
• toString() returns the JSON representation of the object, not the String value of the object (important for easy debugging)
• To me, toDouble() implies that it will convert a non-double representation to a Double. For example, if the document contains the string literal "5" , I would expect that .toDouble() returns 5.0 , but my method would throw an exception saying "trying to read a Double but a String is stored"
• I would like to keep the toDouble() name in case I do add this kind of data conversion in the future

[CLOVIS]

So far I think doc.decode<User>() is the winner

[Matthew Feinberg]

Ah, I saw the <String> type initially and thought it was reading primitives. Being that it's a more complex type, .decode<User> sounds perfect. (The name of the Document type kind of threw me off...)

[Matthew Feinberg]

Side note: I love these kind of discussions because it reveals how we all have our own different assumptions about context. As a library developer, I need to be more careful about that, and this is great exercise. By the way, did you know there's also #C0474L1Q8DR (which I wish got more use than it does).

[CLOVIS]

#C0474L1Q8DR is kinda dead yeah 😕