On Mon, Nov 12, 2012 at 6:37 PM, Sean Corfield seancorfi...@gmail.comwrote:
On Sun, Nov 11, 2012 at 10:31 PM, Denis Labaye denis.lab...@gmail.com
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
On Sun, Nov 11, 2012 at 10:31 PM, Denis Labaye denis.lab...@gmail.com 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
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).
On Sun, Nov 11, 2012 at 6:02 AM, Softaddicts lprefonta...@softaddicts.cawrote:
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
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
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 fact
On Sun, Nov 11, 2012 at 10:56 PM, Softaddicts
lprefonta...@softaddicts.cawrote:
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
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
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
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 Sun, Nov 11, 2012 at 2:26 PM, Mark Engelberg
mark.engelb...@gmail.com 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
On Sat, Nov 10, 2012 at 8:49 PM, Denis Labaye denis.lab...@gmail.com 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]
On Sun, Nov 11, 2012 at 5:59 PM, Sean Corfield seancorfi...@gmail.comwrote:
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
On Sun, Nov 11, 2012 at 6:40 PM, Mark Engelberg
mark.engelb...@gmail.com 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
On Mon, Nov 12, 2012 at 2:59 AM, Sean Corfield seancorfi...@gmail.comwrote:
On Sun, Nov 11, 2012 at 2:26 PM, Mark Engelberg
mark.engelb...@gmail.com 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
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
Convert (:use [lib :only [...]]) = (:require [lib :refer [...] :as ...])
On Sun, Nov 11, 2012 at 12:49 PM, Denis Labaye denis.lab...@gmail.comwrote:
Talking about `use` and `require`:
How are you dealing with the repetition of each namespace configuration?
Each time I create a new namespace
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 denis.lab...@gmail.comwrote:
Sorry, read the question incorrectly.
On Sun, Nov 11, 2012 at 1:02 PM, Softaddicts lprefonta...@softaddicts.cawrote:
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
On Thu, Nov 8, 2012 at 3:19 PM, Softaddicts lprefonta...@softaddicts.ca 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)
--
On Fri, Nov 9, 2012 at 8:28 AM, Sean Corfield seancorfi...@gmail.com wrote:
On Thu, Nov 8, 2012 at 3:19 PM, Softaddicts lprefonta...@softaddicts.ca
wrote:
Removing use would force us to redefine it somehow.
(:use clojure.tools.trace) = (:require [clojure.tools.trace :refer :all)
*sigh* no
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 seancorfi...@gmail.com wrote:
On Thu, Nov 8, 2012 at 3:19 PM, Softaddicts lprefonta...@softaddicts.ca
wrote:
Removing use
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
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).
Hi,
I thought :require with :refer superseded :use :only.
Or am I mistaken?
Las
On Nov 8, 2012 6:03 PM, Jim - FooBar(); jimpil1...@gmail.com 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/**
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
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
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,
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
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
: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
31 matches
Mail list logo