On Mon, Nov 18 2013, Matthew Flatt wrote:
> * Always using `only-in` or `prefix-in` seems too painful. (We know
>that in some languages it's conventional to always prefix imports,
>but those languages don't consider things like `lambda` or the
>application form to be imports.)
Not su
Social processes are good. Participants should try to find
mutually-agreeable balances between proactive and reactive in their
interdependencies.
Some people (myself included) are likely to be scared if some third
party on whom we depend seems to take *too much* of an attitude of "it's
OK if
I am with you on the scenario but I think 'early failure' is good because a
mostly compatible upgrade (widening the API) may have introduced other small
changes and all packages between yours and the modified one may suffer. So I
would love to see that our social processes push people to repair
> In my experience, using plain require and later adding 'except-in' when a
> service module decides to widen its interface is a much simpler approach
> than pre-emptively using 'prefix-in' or 'only-in', especially if you need
> (almost) everything from a (possibly large) library. -- Matthias
Greg Hendershott writes:
> Pre-caveats:
> - Maybe this has been discussed before?
> - This is true (IIUC) of the old Planet as well as the new package system.
> - Maybe it's true of every package system.
It's certainly a problem with many package systems.
I have run into the exact situation
In my experience, using plain require and later adding 'except-in' when a
service module decides to widen its interface is a much simpler approach than
pre-emptively using 'prefix-in' or 'only-in', especially if you need (almost)
everything from a (possibly large) library. -- Matthias
__
> 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 th
I did "only-in" for a while in a large system, proactively, for some of
the reasons you mention. I later decided it was a tedious and
ugly-looking pain in the butt with no actual benefit shown after years
in practice.
I currently try to have reusable modules provide names that are
reasonably
I'll elaborate on Jay's answer --- because I had written most of this
by the time I saw Jay's post, and I think this version of the answer
adds a little.
Despite various efforts, we have no technical solution here, so far:
* Always using `only-in` or `prefix-in` seems too painful. (We know
th
I explicitly mentioned this in the RacketCon talk. PLT generally does
not consider new exports to be backwards incompatible, even though in
principle it is.
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
"inter
On Mon, Nov 18, 2013 at 10:22 AM, Greg Hendershott
wrote:
> p.s. Even in the case where I _know_ that `foo` will soon be provided
> in other-package -- let's say I submit a PR for my handy `foo` to be
> added to that package, with a view toward eventually dropping my own
> version -- the timing co
Pre-caveats:
- Maybe this has been discussed before?
- This is true (IIUC) of the old Planet as well as the new package system.
- Maybe it's true of every package system.
With that said:
Technically, to maintain backward compatibility, a package should
_never_ `provide` a new name in an existing
12 matches
Mail list logo
