> I explicitly mentioned this in the RacketCon talk. Sorry, I was distracted because I was on-deck to give my talk next. :)
> PLT generally does > not consider new exports to be backwards incompatible, even though in > principle it is. In general I agree with that. Certainly when I'm building things locally, it's not a huge practical issue. I know there's a chance a new version might introduce a collision that I need to fix. If so, I fix it -- or if it's too painful, I avoid the new version, maybe. The thing that struck me lately is the scenario where the user is building it in the field. They might get newer pieces than I knew about, last I updated my package. I wouldn't know it broke until they told me. If I put a package out there, I'm willing to maintain it as-needed. But I also want to avoid unnecessary breakage and fire drill hotfixes. Using `only-in` or `prefix-in` is a way to leave my latest package version out there in a form that's more durable. Maybe that was already obvious to others as a best-practice. It only became obvious to me when doing some end-user technical support. :) So I wanted to share that. > I think the only-in/prefix-in idea is the right way to go, but it is > pretty painful. There are a few ways to make it simpler. I have a > "interface" experiment that makes it so you can define an interface to > a module separate from its implementation: > > https://github.com/jeapostrophe/exp/blob/master/interface/interface-in.rkt > > I think that using such a system in a more integrated way throughout > Racket is part of "Racket 2". Well, I haven't found it excessively painful. Not even manually. (So far. Maybe a painful case lies around the corner.) A tool that can check `require`s generally -- including entire modules you don't use -- could probably spit out a list of the item actually used from a module? Or maybe that's easier said than done. The interface idea for the future sounds interesting, too. ____________________ Racket Users list: http://lists.racket-lang.org/users
