Ops
NAME
Config::BINDish::Ops - operators for Config::BINDish
SYNOPSIS
my $cfg = Config::BINDish.new;
$cfg.read: string => q:to/CFG/;
top-opt "is top";
cluster "generic" {
the-answer 42;
group {
service "api" {
host "h1" {
ip "192.168.1.2";
}
host "h2" {
ip "192.168.1.3";
interface "eth2";
}
}
}
}
say $cfg ∷ :cluster<generic> ∷ :group ∷ :service<api> ∷ :host<h2> ∷ <interface ip>; # eth2 192.168.1.3
say $cfg.top ∷ :cluster<generic> ∷ :group ∷ :service<api> ∷ :host<h2> ∷ <interface ip>; # eth2 192.168.1.3
DESCRIPTION
Request Operator ∷
Request operator is a front-end to Config::BINDish::AST::Block get method. It is available in
either Unicode (∷) or ASCI (::) form. Both are totally identical. But since the ASCI form also serves as name
space separator for long names like Config::BINDish::Ops, there is a slight chance that it would clash that. For
this reason the Unicode version is preferable.
The operator has list associativity making it follow any rules that apply to
the comma operator.
To import any form of the operator into your code namespace, use Config::BINDish with either of both arguments:
use Config::BINDish <op>; # Import Unicode version
use Config::BINDish <ascii-op>; # Import ASCII version
use Config::BINDish <op ascii-op>; # Import both versions
Syntax And Semantics
The operator mimics Raku's long name resolution behaviors. I.e. the meaning of:
$cfg ∷ :outer ∷ :inner<named> ∷ "option";
is to:
find block outer in the config top-level
then find subblock inner with name "named" in the outer block
then find option in the inner block and return its value.
Elements of the path defined with the operator can be either Pairs or strings when referring to a block. Or they could be either a string, or a list or any other Positional object which contains a list of string,when referring an option.
In a multi-component path all elements between the first and the last ones are always treated as block references.
The first element must be either an Config::BINDish instance, or a Config::BINDish::AST::Block.
The last path element defines the kind of request. If it is a string, or a Positional, or a Code then the operator is expected to return an option. If the last element is a Pair then it is expected to return a block.
The following examples are based on the #SYNOPSIS example:
$cfg ∷ :cluster<generic> ∷ :group; # returns a block object
$cfg ∷ :cluster<generic> ∷ "the-answer"; # returns 42
$cfg ∷ :cluster<generic> ∷ :group ∷ :service<api> ∷ :host<h2> ∷ <interface ip>; # ("eth2", "192.168.1.3")
$cfg ∷ :cluster<generic> ∷ :group ∷ :service<api> ∷ :host<h2> ∷ { <interface ip> }; # ("eth2", "192.168.1.3")
In the last example the code block is supplied with :host<h2> block object as its argument. The return value of the
block is turned into a List to be used as a positional. It means, for example, that:
$cfg ∷ :cluster<generic> ∷ { "the-answer" }
will return a list with a single element being 42 integer.
The operator can be adverbed with Config::BINDish::AST::Block method get named parameters:
$cfg ∷ :cluster<generic> ∷ <the-answer> :raw; # returns an option object
$cfg :: :cluster<generic> ∷ <group> :block; # returns a block object
Also, because of the operator reliance upon the `get` method, it can return default values for elements missing from the configuration file.
SEE ALSO
COPYRIGHT
(c) 2023, Vadim Belman <[email protected]>
LICENSE
Artistic License 2.0
See the LICENSE file in this distribution.