https://kotlinlang.org logo
Join Slack
Powered by
Trying to understand which parts of okhttp are "va...
# squarelibraries
c
Trying to understand which parts of okhttp are "value classes" Struggling with whether or not https://square.github.io/okhttp/3.x/okhttp/okhttp3/Request.html is a value class because of it's description
An HTTP request. Instances of this class are immutable if their body is null or itself immutable.
Like if this was written in kotlin would it just be a data class?
m
You can check the sources. It doesn't override 
equals
and 
hashCode
.
In Kotlin it isn't written as a data class. And even if it would be considered a value class I doubt it would use data modifier due to the copy method.
j
Right. No data classes in public API ever.
A 
Request
is value-y
👀 1
yes black 1
The problem is really the body, which is only materialized when needed. This means it could change (such as the contents of a file). It could also be a one-shot body such that it cannot be read twice.
c
No (kotlin?) 
data
classes in public API. Very interesting?!
j
c
cool. so if Request would be rewritten in kotlin, the only thing that would really change is that the builder would go away?
I was thinking of maybe marking it as a 
data
class because that would be a signal that it is a value class.
m
OkHttp has been migrated to Kotlin for quite a while now. You're looking at 
3.x
docs. Current version is 
5.1.0
j
Migrated to Kotlin but maintaining binary compatibility with the Java API
m
Right, this probably affects Kotlin's API shape a bit
c
whoops. howd i miss the memo on that. 🤦
i guess google searches kept taking me to 3.x sources. thanks. and yeah i just saw that Request.kt still maintains a builder, but makes sense that binary compatability is the reason for that.
for some background. im writing an sdk (internal only for now, and ive never written an sdk before... really im only contributing like 10% of my time to this project, and others are on it 100%) and there was a decision to write a thin layer on top of the http client. and so im rewriting Request and Response and theres a general convo going on how it should be structured. i was firmly in belief that it should just be a data class with no methods on it.
y
I think at these layers the domains are completely different. OkHttp is modelling the HTTP User Agent domain. Which has warts and evolves. And is a public API that can't break. Presumably your domain is the focus of your request/response. So I doubt it's the right design to copy.
👀 1
3 Views
Open in Slack
PreviousNext
Powered by