search

scala / slip

obsolete — archival use only
67 stars 15 forks source link

SLIP 27 Tracking #23

Closed dickwall closed 7 years ago

dickwall commented 8 years ago

SLIP 27 - Views Redesign, at

https://github.com/scala/slip/blob/master/text/0027-collection-view-redesign.md

Is now under public review. Please comment here if you have notes or requests regarding this SLIP.

dickwall commented 8 years ago

From the September SLIP meeting, it appears that an initial step will be to deprecate existing views, possibly as soon as the 2.12 release. Josh, please comment progress for that here. Thanks.

SethTisue commented 8 years ago

I don't think we know how @odersky feels about the possibility of deprecating the existing views before a replacement is ready. as best I can recall without re-viewing the video, after I mentioned the possibility, he said something about in the context of a hypothetical sentence (like “if we did deprecate the old views, it would have to be in 2.12”, that kind of thing) without expressing a definite viewpoint on it?

odersky commented 8 years ago

I don't think we should deprecating things before we have an alternative in place. This would create needless busywork for those people that do care about deprecations. They would have to get rid of views, maybe rewrite using strict collections or iterators, and then in 2.13 switch back to views.

Can we be more fine grained? Are there things that we know will definitely go away with new views? Then we should deprecate these things rather than deprecate .view wholesale.

dickwall commented 8 years ago

I will say it is a pet peeve of mine when an API is deprecated (resulting in lots of compiler warnings) and no alternative is available to replace it with. It's the "no broken windows" argument. If you are trying to keep compiler warnings to zero, this makes it difficult (nee impossible). On the other hand, what does it mean for an implementation in the 2.13 timeframe for redesigned views if the current views are not deprecated in the current version? Assuming a trial library will be available during the 2.12.x lifecycle in the leadup to a 2.13 inclusion, how will that work? What are the implications for packages used for the new API?

odersky commented 8 years ago

I think we need to agree on a "new view" proposal first. Then we know what does not carry over cleanly and then we can deprecate these things.

SethTisue commented 8 years ago

I find myself wishing there were levels of deprecation, or some kind of semi- or pre-deprecation, like, "already using this? you're OK for now if your tests are passing, but consider alternatives. oh, you're new here? better if you don't use this in new code”

SethTisue commented 7 years ago

This will be taken up by Lightbend and the Scala Center for Scala 2.13.