On Mon, Nov 12, 2012 at 6:37 PM, Sean Corfield wrote:
> On Sun, Nov 11, 2012 at 10:31 PM, Denis Labaye
> wrote:
> > Most of my Clojure usage is as a scripting language (where other would
> use
> > Python or Ruby).
> > I usually don't plan in advance how my program will be splitted in
> > namespac
On Sun, Nov 11, 2012 at 10:31 PM, Denis Labaye wrote:
> Most of my Clojure usage is as a scripting language (where other would use
> Python or Ruby).
> I usually don't plan in advance how my program will be splitted in
> namespaces :
> I start from one namespace that does everything, let it grow,
On Mon, Nov 12, 2012 at 2:59 AM, Sean Corfield wrote:
> On Sun, Nov 11, 2012 at 2:26 PM, Mark Engelberg
> wrote:
> > I can relate to Denis' issue. I find it pretty common to have a common
> set
> > of dependencies across every file in a project.
>
> Well, I have to say I was puzzled by Denis' po
On Sun, Nov 11, 2012 at 6:40 PM, Mark Engelberg
wrote:
> set, string, numeric-tower, combinatorics all provide fundamental operations
> I need throughout my code.
Ah, very different fields of work. Makes sense.
> My work doesn't usually involve creating a standalone compiled program. I
> move a
On Sun, Nov 11, 2012 at 5:59 PM, Sean Corfield wrote:
> Denis, Mark, could you speak to what sort of things you're using these
> for that make it convenient to have them in every namespace?
>
>
set, string, numeric-tower, combinatorics all provide fundamental
operations I need throughout my code.
On Sat, Nov 10, 2012 at 8:49 PM, Denis Labaye wrote:
> How do you avoid repeating this ? A clojure macro?, IDE support?, ... ?
http://code.google.com/p/clj-nstools/
The nstools library has a tool to help with this.
(ns myproject.base
(:require [clojure.set :as set]
[clojure.
On Sun, Nov 11, 2012 at 2:26 PM, Mark Engelberg
wrote:
> I can relate to Denis' issue. I find it pretty common to have a common set
> of dependencies across every file in a project.
Well, I have to say I was puzzled by Denis' post because I definitely
don't have common dependencies across every
This is the best I can come with in a short time:
(ns higiebus.services.depcy-profiles
"Shortcut to common dependency profile")
(defmacro basic-service-deps
[]
`(do
(require [higiebus.services.config :as conf] [higiebus.services.loggers
:as log]
[clojure.string :as s])
On Nov 8, 2012, at 12:39 PM, Softaddicts wrote:
> Mmmh, maybe I should create a pocket guide for elderly Clojure coders
> someday...
An aside: I'm giving a keynote at the ACCU conference titled "Cheating Decline:
Acting now to let you program well for a really long time" I'll be looking for
I can relate to Denis' issue. I find it pretty common to have a common set
of dependencies across every file in a project. Copying and pasting this
header to every file and updating changes manually across every file
doesn't feel like a very robust solution. This is something that has
bothered m
On Sun, Nov 11, 2012 at 10:56 PM, Softaddicts
wrote:
> Since you use emacs, why not create a key binding to an expression that
> would get
> evaluated in the REPL ? or to eval the zxcv macro ?
>
> Luc P.
>
Luc,
Yes, the solutions you described (Clojure utility macro, or Emacs key
binding) are po
Since you use emacs, why not create a key binding to an expression that would
get
evaluated in the REPL ? or to eval the zxcv macro ?
Luc P.
> I just find this puzzling, the "coding standards" emphasizes reducing
> dependencies.
> Now if you add dependencies in your boiler plate that may in
I just find this puzzling, the "coding standards" emphasizes reducing
dependencies.
Now if you add dependencies in your boiler plate that may in fact not be used
by the source code
in the current name space, how can a human reader understand your dependencies
by reading the top nth lines of your
On Sun, Nov 11, 2012 at 6:02 AM, Softaddicts wrote:
> How does that shrink his boilerplate ?
>
> Why such a long boilerplate ? Do you need the string library everywhere ?
> Why not drop :only ?
>
oftentimes, I am at the REPL, and I know this particular function in
clojure.set (or clojure,io, or .
I have not heard from anyone that
http://dev.clojure.org/display/design/Library+Coding+Standards is out of
date, so I take that to mean that the following is still the standard:
"Be explicit and minimalist about dependencies on other packages.
(Prefer the :only option to use and require)."
-Da
Sorry, read the question incorrectly.
On Sun, Nov 11, 2012 at 1:02 PM, Softaddicts wrote:
> How does that shrink his boilerplate ?
>
> Why such a long boilerplate ? Do you need the string library everywhere ?
> Why not drop :only ?
>
> Luc P.
>
>
> > Convert (:use [lib :only [...]]) => (:require
How does that shrink his boilerplate ?
Why such a long boilerplate ? Do you need the string library everywhere ?
Why not drop :only ?
Luc P.
> Convert (:use [lib :only [...]]) => (:require [lib :refer [...] :as ...])
>
> On Sun, Nov 11, 2012 at 12:49 PM, Denis Labaye wrote:
>
> > Talking abou
Convert (:use [lib :only [...]]) => (:require [lib :refer [...] :as ...])
On Sun, Nov 11, 2012 at 12:49 PM, Denis Labaye wrote:
> Talking about `use` and `require`:
>
> How are you dealing with the repetition of each namespace "configuration"?
>
> Each time I create a new namespace I add the foll
Talking about `use` and `require`:
How are you dealing with the repetition of each namespace "configuration"?
Each time I create a new namespace I add the following boilerplate:
(ns foo.bar
(:use [clojure
[pprint :only [pprint pp]]
[repl
Yep but still longer to type :) we are in the process of shrinking the code
base,
nit expanding it, any bytes count :))
> On Fri, Nov 9, 2012 at 8:28 AM, Sean Corfield wrote:
> > On Thu, Nov 8, 2012 at 3:19 PM, Softaddicts
> > wrote:
> >> Removing use would force us to redefine it somehow.
>
On Fri, Nov 9, 2012 at 8:28 AM, Sean Corfield wrote:
> On Thu, Nov 8, 2012 at 3:19 PM, Softaddicts
> wrote:
>> Removing use would force us to redefine it somehow.
> (:use clojure.tools.trace) => (:require [clojure.tools.trace :refer :all)
*sigh* no paredit in Gmail and I haven't had my coffee y
On Thu, Nov 8, 2012 at 3:19 PM, Softaddicts wrote:
> Oh, I must say that I rarely use the Eclipse debugger. Tracing does most of
> the job.
> Removing use would force us to redefine it somehow.
(:use clojure.tools.trace) => (:require [clojure.tools.trace :refer :all)
--
Sean A Corfield -- (904)
> :require :as is always good and generally preferred over :refer or :use
:only.
I think we all agree with this, but in reality :use with/without :only is
very widely used in a number of real project I've seen on github.
:use (especially without :only) makes code reading painful and usually
read
1/2 +
Use is still a short way of including mundane stuff like tools.trace and a few
others. We leave :use clojure.tools.trace in place in namespaces once we
have done
it.
Doing it in the REPL each time we need it while debugging is tedious.
Oh, I must say that I rarely use the Eclipse d
Am Donnerstag, 8. November 2012 19:42:26 UTC+1 schrieb Luc:
>
> I am pragmatic and quite lazy, I use require with an alias
>
inc
An explicit call to use every now and then on the REPL, but no :use in ns.
IMHO use and :use can be removed from the language.
--
You received this message because
Sorry, yes, to clarify -- :require :as is always good and generally
preferred over :refer or :use :only.
Justin
On Thursday, November 8, 2012 1:42:26 PM UTC-5, Luc wrote:
>
> I am pragmatic and quite lazy, I use require with an alias and use mostly
> with stuff like
> clojure.tools.trace, clo
I am pragmatic and quite lazy, I use require with an alias and use mostly with
stuff like
clojure.tools.trace, clojure.pprint where selecting explicit vars brings
no or little value (in my opinion).
You either need most of the public vars or the potential name conflict is a
remote
possibility a
Current best practice in my view:
For Clojure 1.4+, do not use :use at all. Use :require :refer
(judiciously). :refer :all is almost never a good idea.
For Clojure 1.3 and below, :use :only is strongly encouraged. Bare :use is
almost never good.
Justin
On Thursday, November 8, 2012 11:57:21 A
Hi,
I thought :require with :refer superseded :use :only.
Or am I mistaken?
Las
On Nov 8, 2012 6:03 PM, "Jim - FooBar();" wrote:
> I'm pretty sure this is still valid
> :)
>
> Jim
>
> On 08/11/12 16:57, David McNeil wrote:
>
>> I notice the following item at http://dev.clojure.org/**
>> displa
I'm pretty sure this is still valid
:)
Jim
On 08/11/12 16:57, David McNeil wrote:
I notice the following item at
http://dev.clojure.org/display/design/Library+Coding+Standards
"Be explicit and minimalist about dependencies on other packages.
(Prefer the :only option to use and require)."
I notice the following item at
http://dev.clojure.org/display/design/Library+Coding+Standards
"Be explicit and minimalist about dependencies on other packages.
(Prefer the :only option to use and require)."
The page was last edited on Mar 29, 2011 and ns usage has been discussed a
fair bit
31 matches
Mail list logo
