Liking cljdoc? Tell your friends :D

active.clojure.condition

Conditions, protocol for communicating the causes of exceptions.

This provides infrastructure for building condition objects. A condition object provides information about the cause of an exception. Conditions thus form a protocol.

Clojure ex-info objects do not, by themselves, enough to form such a protocol, as they do not allow classifying an exception easily.

This condition system builds on the design of R6RS Scheme.

Condition objects are represented as specially marked ex-info objects.

One notable difference to the R6RS design is that there is no user-facing type for 'simple conditions', nor are they regular records.

Conditions, protocol for communicating the causes of exceptions.

This provides infrastructure for building *condition* objects.
A condition object provides information about the cause of an exception.
Conditions thus form a protocol.

Clojure `ex-info` objects do not, by themselves, enough to form such
a protocol, as they do not allow classifying an exception easily.

This condition system builds on the design of
[R6RS Scheme](http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-8.html#node_sec_7.2).

Condition objects are represented as specially marked `ex-info` objects.

One notable difference to the R6RS design is that there is no user-facing type for
'simple conditions', nor are they regular records.
raw docstring

active.clojure.config

Application configuration via a big map.

A configuration is a nested key-value map.

It contains top-level settings and sections of qualified settings, like so:

{:top-level-setting-key 'foo
 {:section-key
  {:section-setting 'bar}}}

Additionally, a config contains profiles with additional settings that can be mixed in, like so:

{:top-level-setting-key 'foo
 {:section-key
  {:section-setting 'bar}}
 {:profiles
  {:dev
   {:top-level-setting-key 'bar
    {:section-key
     {:section-setting 'baz}}}}}}

Each profile has the same format as the top-level configuration itself (sans the :profiles key).

Application configuration via a big map.

A configuration is a nested key-value map.

It contains top-level settings and sections of qualified settings, like so:

    {:top-level-setting-key 'foo
     {:section-key
      {:section-setting 'bar}}}

Additionally, a config contains *profiles* with additional
settings that can be mixed in, like so:

    {:top-level-setting-key 'foo
     {:section-key
      {:section-setting 'bar}}
     {:profiles
      {:dev
       {:top-level-setting-key 'bar
        {:section-key
         {:section-setting 'baz}}}}}}

Each profile has the same format as the top-level configuration itself
  (sans the `:profiles` key).
raw docstring

active.clojure.dynj

Thin layer over dynamic vars for implicit dependency injection. Dynjs can be used to have better control over side effects, to abstract over different possible interpretations of an aspect of a program or to make things easier for testing.

Main usage patterns:

(declare-dynj eff [a])

(defn foo []
  (assert (= 4 (eff 2))))

(defn square [a] (* a a))

(foo) ;; => throws exception

(binding [eff square]
  (foo))

((with-bindings* {#'eff square} foo))

Thin layer over dynamic vars for implicit dependency injection. Dynjs
can be used to have better control over side effects, to abstract
over different possible interpretations of an aspect of a program or
to make things easier for testing.

Main usage patterns:

```
(declare-dynj eff [a])

(defn foo []
  (assert (= 4 (eff 2))))

(defn square [a] (* a a))

(foo) ;; => throws exception

(binding [eff square]
  (foo))

((with-bindings* {#'eff square} foo))

```
raw docstring

active.clojure.functions

Redefines higher order functions and function combinators from clojure.core via applicable records (ifn? but not fn?). The advantage is, that those objects compare = if they are created from equal arguments. Disadvantages are that they are probably a bit slower. They also don't implement some additional protocols like Runnable yet.

Redefines higher order functions and function combinators from
clojure.core via applicable records (ifn? but not fn?). The
advantage is, that those objects compare = if they are created from
equal arguments. Disadvantages are that they are probably a bit
slower. They also don't implement some additional protocols like
Runnable yet.
raw docstring

active.clojure.lens

Lenses should obey the following laws:

GetPut, or YankShove:

(= (yank (shove data my-lens val)
         my-lens)
   val)

Meaning: you get back what you put in.

PutGet, or ShoveYank:

(= (shove data
          my-lens
          (yank data my-lens))
   data)

Meaning: putting back what you got does not change anything.

PutPut, or ShoveShove:

  (= (shove data my-lens val-1)
     (shove (shove data my-lens val-2) my-lens val-1))

Meaning: second shove wins, or shoving once is the same as shoving twice.

A lens that satisfies these three laws is usually called "very well-behaved". See also active.clojure.lens-test/lens-laws-hold.

Lenses should obey the following laws:

GetPut, or YankShove:

    (= (yank (shove data my-lens val)
             my-lens)
       val)

Meaning: you get back what you put in.

PutGet, or ShoveYank:

    (= (shove data
              my-lens
              (yank data my-lens))
       data)

Meaning: putting back what you got does not change anything.

PutPut, or ShoveShove:

      (= (shove data my-lens val-1)
         (shove (shove data my-lens val-2) my-lens val-1))

Meaning: second shove wins, or shoving once is the same as shoving twice.

A lens that satisfies these three laws is usually called "very well-behaved".
See also `active.clojure.lens-test/lens-laws-hold`.
raw docstring

active.clojure.match

Syntactic sugar for map matching around core.match.

Syntactic sugar for map matching around `core.match`.
raw docstring

active.clojure.record-spec

A re-implementation of active.clojure.record that makes use of Clojure's new spec library. Define records the same ways as in the old implementation or use the new syntax to automatically generate specs. If a field has no explicit spec, defaults to any?.

A re-implementation of `active.clojure.record` that makes use of
Clojure's new spec library. Define records the same ways as in the old
implementation or use the new syntax to automatically generate specs.
If a field has no explicit spec, defaults to `any?`.
raw docstring

active.clojure.test-condition

Support for using clojure.test and conditions together.

Support for using `clojure.test` and conditions together.
raw docstring

No vars found in this namespace.

active.clojure.test-condition-cljs

No vars found in this namespace.

active.clojure.validation

This namespace provides the utilities for applicative data validation. Chiefly, it provides the validation function that defines a data validation. It also provides predefined data validators for common use-cases (ints, strings, booleans, ...).

Example:

(defn example-validation
  [id name]
  (validation (fn [id name] {:id id :name name})
              (validate-pos-int id :id)
              (validate-string name)))

(example-validation [42 "name"])
;; => active.clojure.validation/ValidationSuccess{:candidate {:id 42, :name "name"}}
(example-validation [42 23])
;; => active.clojure.validation/ValidationFailure{:errors
;;      [active.clojure.validation/ValidationError{:candidate 23,
;;                                                 :message :active.clojure.validation/string,
;;                                                 :label nil}]}
(example-validation ["name" 42])
;; => phoenix.common.validation/ValidationFailure{:errors
;;      (active.clojure.validation/ValidationError{:candidate "name",
;;                                                 :message :active.clojure.validation/pos-int,
;;                                                 :label :id}
;;       active.clojure.validation/ValidationError{:candidate 42,
;;                                                 :message :active.clojure.validation/string,
;;                                                 :label nil})}
This namespace provides the utilities for applicative data validation.
Chiefly, it provides the [[validation]] function that defines a data
validation.  It also provides predefined data validators for common
use-cases (ints, strings, booleans, ...).

Example:
```
(defn example-validation
  [id name]
  (validation (fn [id name] {:id id :name name})
              (validate-pos-int id :id)
              (validate-string name)))

(example-validation [42 "name"])
;; => active.clojure.validation/ValidationSuccess{:candidate {:id 42, :name "name"}}
(example-validation [42 23])
;; => active.clojure.validation/ValidationFailure{:errors
;;      [active.clojure.validation/ValidationError{:candidate 23,
;;                                                 :message :active.clojure.validation/string,
;;                                                 :label nil}]}
(example-validation ["name" 42])
;; => phoenix.common.validation/ValidationFailure{:errors
;;      (active.clojure.validation/ValidationError{:candidate "name",
;;                                                 :message :active.clojure.validation/pos-int,
;;                                                 :label :id}
;;       active.clojure.validation/ValidationError{:candidate 42,
;;                                                 :message :active.clojure.validation/string,
;;                                                 :label nil})}
```
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close