Skip to content

Latest commit

 

History

History
54 lines (33 loc) · 1.38 KB

boolean.md

File metadata and controls

54 lines (33 loc) · 1.38 KB
Raw

Definition of Bool

Problem

Inconsistent use of booleans in various parts of Elektra.

Constraints

  • needs to be string

Assumptions

Considered Alternatives

  • only check presence or absence (no cascading override of already present key possible)
  • use booleans as in CMake, which allows on/off, true/false, ... (would need convenience across the code)
  • do not accept a specification with type = boolean without a default

Decision

Only the strings 0 and 1 are allowed in the KeySet for type = boolean, for both values and defaults. Everything else should lead to errors in checkers (in kdbSet).

A spec with type = boolean without a specified default should be interpreted as default = 0.

Example for an implementation in C in an application:

if (k != NULL && strcmp(keyString(k), "1") == 0) {/*true*/} else {/*false*/}

Storage plugins are allowed any representation as suitable, e.g., a JSON plugin might render 1 as true.

The type checker plugin should allow

  • non-presence
  • the string "0"
  • the string "1"

Rationale

  • most easy to implement
  • allows non-presence to be false
  • plugins allow us to convert to any other behavior

Implications

  • Storage plugins are only allowed to emit 0 or 1 as key values
  • Applications either get 0 or 1, or (without a key) can safely assume that false is meant

Related Decisions

Notes