-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Formatted <: IO to avoid invalidations #397
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #397 +/- ##
==========================================
+ Coverage 91.71% 92.22% +0.50%
==========================================
Files 10 10
Lines 712 707 -5
==========================================
- Hits 653 652 -1
+ Misses 59 55 -4 ☔ View full report in Codecov by Sentry. |
I agree that this change is strange because it makes |
The discussion at KristofferC/OhMyREPL.jl#355 makes me believe that it isn't really possible, unfortunately (see notably this comment). |
My understanding of that comment makes me think that there are a few options to improve things:
|
I believe in theory these were both considered, as explained in the answer to that comment: KristofferC/OhMyREPL.jl#355 (comment). In practice, it seems like the slightly less intuitive/ideal design brings good trade-offs, with less code churn and desirable behavior, one downside being invalidations popping up. Ideally it's not downstream code that should deal with this, but I'm exploring whether we could alleviate this deliberate downside with as noticeable of an impact here. |
As |
There is already a |
The idea is to address #396; subtyping |
This should be fixed by JuliaLang/julia#55593 I think it might make sense for Also making |
Nice, thanks! |
Addresses #396, and further seems to simplify the implementation a little.
This change is a bit weird, as
Formatted
itself does not semantically represent anIO
type, it is onlyStream
that does. But sinceStream
can only subtype a single abstract type, that is the only way to make itStream <: ... <: IO
such that the type hierarchy is preserved.The potential drawback I see is that it probably causes more specialization, threading
Stream
through IO functions. At first I attempted to keep the more specificread
/write
methods forStream
, but becauseStream
is now anIO
ambiguity errors pop up which require more methods to be defined manually to be resolved, at which point I thought having a minimal IO implementation might be better. I can try to maximally avoid specialization by adding these methods back, but it is quite likely that other ambiguity errors pop up in the future if going down that path. I believe that the invalidation fixes outweigh the added specialization.I'm happy to discuss/drop this PR if the subtyping change it not desired, in which case we can try to come up with another solution to #396 (if it exists). I'm also curious to know if there was some discussion about having
Stream <: IO
, seeing that it implements lots of IO interface functions.