+1 after 1.2 On May 5, 11:24 am, Chas Emerick <cemer...@snowtide.com> wrote: > We've been able to treat ns declarations *as* declarations for the > most part, which is nice. IMO, last-var-wins pulls the veil away even > more on the fact that namespaces are probably the most pervasively- > stateful part of clojure. > > I remember various proposals floating around a long time ago to load > the entire file of each ns and do some name resolution before defining > any vars so as to avoid the need for declare. Maybe that could be > resurfaced, and local declarations always given priority over referred > namespaces? I've no idea how difficult that would be, and may be way > out of scope for a 1.2 release, but it seems like that would kill a > variety of birds with one stone, and maybe slightly simplify the > mental model that one needs to have in place to understand namespaces. > > - Chas > > On May 5, 10:32 am, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > > > > > For a long time, people have been suggesting that various libraries be > > promoted from contrib into clojure core. Last week, we started making > > some of the necessary code changes. > > > ==== THE PROBLEM ==== > > While the changes to Clojure itself are only additive and non- > > breaking, they can nevertheless cause breakages in your code: > > > (1) If you defined your own function 'foo', and Clojure gets a new > > core function named 'foo', your definition would cause an error. > > (2) Third party libs can create situation #1 behind your back. In > > fact, this situation is almost guaranteed to occur when promoting > > functions from contrib! If clojure.contrib.seq/group-by goes into > > core, then people who were using the contrib version could get an error. > > > I (and other library authors) spent some time and effort to adapt to > > these changes, but it is a PITA. It has already caused cascading > > breakage in circumspec, labrepl, leiningen, swank, and incanter (to > > name a few). > > > One solution would be consensus around, and rigorous correct use of, > > an elegant dependency management tool. Since that ain't likely, here's > > another possibility: > > > ==== A SIMPLER SOLUTION: WARN, DON'T ERR ==== > > So Rich has given us something else: as of yesterday's commit > > ab9a567faecc8cfde4625654fe9bb92988d7494d, attempting to define or > > refer a var that is already referred from another namespace causes a > > *warning*, not an *error*. So, for the example of 'group-by' being > > moved into core, you might see the following warning message when > > using a library that isn't updated yet: > > > WARNING: group-by already refers to: #'clojure.core/group-by in > > namespace: incanter.core, being replaced by: #'incanter.core/group-by > > > That's a lot better than being dead with an error. > > > ==== GETTING RID OF THOSE WARNINGS ==== > > In this case, the warning is innocuous: Incanter uses the (now > > deprecated) contrib group-by, and doesn't get the new one added to > > clojure.core. Library authors can then either > > > (1) Update their code to use the new things core gives them. If they > > defined the function themselves, just remove the definition. If they > > referred in a third-party implementation, simply removed the use/ > > require/refer. > > (2) Continue to use their own implementation of the name. This > > requires *adding* an exclude, e.g. (:refer-clojure :exclude [group-by]) > > > ==== PROMOTION AND DEPRECATION ==== > > > With "warn on name collision" in place, the sane way to promote from > > one library to another is to copy the vars into their new home, but to > > also leave the old ones in place (for a while). The old vars can be > > marked with {:deprecated "some.version.no"}, and old clients can > > continue to use them. > > > So, this morning (commit 95dddbbdd748b0cc6d9c8486b8388836e6418848), I > > put the promoted seq fns back into contrib as well. The result of this > > should be that old code will work (with warnings telling you which > > libs need updates) instead of stopping dead (with an error). > > > ==== THIS AIN"T SET IN STONE! ==== > > We are testing this approach out. If it causes unforeseen foulups, we > > can always go back to the old way. > > > But I for one think it is awesome. It is more consistent with > > Clojure's dynamic approach in general. Not only does it make upgrades > > less painful, it also makes it easier to try things out at the REPL. > > No more "you can't def that cause somebody else did already." Now life > > at the REPL is "Do what I told you, period." > > > I hope you will like this idea and encourage Rich to make it permanent. > > > Stu > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group > > athttp://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group > athttp://groups.google.com/group/clojure?hl=en
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en