head

C<Config::BINDish::Actions> - default actions for
L<C<Config::BINDish::Grammar>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar.md>


This class is the default to be used for parsing configs. It builds
L<C<Config::BINDish::AST>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/AST.md>
tree representation of a config data which is then provided to application code via
L<C<Config::BINDish>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish.md>
attribute C<$.top>. The tree can be used to fetch required configuration data, see
L<C<Config::BINDish::AST>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/AST.md>.


Most of the methods correspond to named rules in
L<C<Config::BINDish::Grammar>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar.md>.
In this section only utility methods are documented.


C<make-container(Config::BINDish::Grammar::Value:D $val)>


Method creates a new instance of
L<C<Config::BINDish::AST::Value>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/AST/Value.md>
from its grammar counterpart.


C<enter-parent(Config::BINDish::AST::Parent:D $inner --> Config::BINDish::AST::Parent:D)>


C<enter-parent(Config::BINDish::AST::Parent:U $inner, |profile --> Config::BINDish::AST::Parent:D)>


Method is invoked when a new
L<C<Config::BINDish::AST::Parent>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/AST/Parent.md>
node is to be created. For example, this class uses it when creates the C<TOP> node and each time a new block node is
created.
L<C<Config::BINDish::Extendabale>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Extendabale.md> also uses this method for another kinds of nodes.


If C<$inner> is an undefined typeobject then the method first creates an instance of it using method `new` and using
C<profile> as its arguments:


L<C<Config::BINDish>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish.md>,
L<C<Config::BINDish::Grammar>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar.md>


AUTHOR

root

para

L<Examples| file:../examples/index.podlite>


L<Download |file:../download/index.podlite>


React

=begin React :component<HeaderCol> :id<menu> 
=para L<Documentation|/doc/introduction>
=para L<Modules| /mods>
=para L<Examples| file:../examples/index.podlite>
=para L<Download |file:../download/index.podlite>
=para L<About|file:../about/index.podlite>
=para 🔍 K<⌘K>/K<ctrl-K>
=end React


HEADER

FOOTER

Actions

C<Config::BINDish::AST> - the standard C<Config::BINDish> AST tree representation


As a module C<Config::BINDish::AST> defines all standard AST node classes used by
L<C<Config::BINDish::Actions>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Actions.md>
to build the resulting representation of the parsed configuration.


As a class C<Config::BINDish::AST> is the base class for all other AST node classes.


L<C<Config::BINDish::AST::Parent>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/AST/Parent.md> C<$.parent>


Points to the parent node. Will stay undefined for the C<TOP> node.


C<set-parent(Config::BINDish::AST::Parent:D $parent)>


Returns current node name, based on the node class name. If the name starts with I<Config::BINDish::AST::> then this
part is stripped off. Otherwise the class name is considered to be the name.


Dumps current node' string representation which consists of C<ast-name> and C<gist> and would be indented by C<$level>
white spaces.


C<register-type(Str:D $ast-name, Mu \ast-type)>


Method registers an C<ast-type> class under C<$ast-name>. C<new-ast> method (see below) can later create a node instance
based on its registered name.


C<new-ast(Str:D $node-type, |profile --> Config::BINDish::AST:D)>


Creates a new instance of ast node based on its name. The name can be either a registered AST node name, see
C<register-type> method above; or a short name under C<Config::BINDish::AST::> namespace. If no associated AST type
object is found then a failure wrapped around
L<C<Config::BINDish::X::AST::DoesnExists>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/X/AST/DoesnExists.md>
is returned.


For example, with the following statement:


Config::BINDish::AST.register-type("MyAppNode", MyApp::Config::AST::Node);


Config::BINDish::AST.new-ast("MyAppNode", :foo(42), :bar("The Answer")); # An instance of My::App::Config::AST::Node


For one of the standard AST nodes one can:


Config::BINDish::AST.new-ast('Block', :name(...), :class(...), ...); # An instance of Config::BINDish::AST::Block


Returns the topmost node, or, in other words, the root of the AST tree.


item

L<C<Config::BINDish>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish.md>,
L<C<Config::BINDish::Aactions>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Aactions.md>


C<Config::BINDish> - parse BIND9/named kind of config files


SYNOPSIS

my $cfg = Config::BINDish.new;
$cfg.read: string => q:to/CFG/;
server "s1" {
    name "my.server";
    paths {
        base "/opt/myapp";
        pool "files" static {
            "pub/img";
            "static/img";
            "docs";
        };
        pool "files" dynamic {
            "users/reports";
            "system/reports"
        }
    }
}
CFG
say $cfg.top.get( :server("s1") => :paths => :pool("images") => 'root' ); # ./pub/img


This module is very much experimental in the sense of the API methods it provides. The grammar is expected to be more
stable, yet no warranties can be given at the moment.


In this documentation I'll be referring to the configuration format implemented by the module as I<BINDish config> or
simply I<BINDish>.


BINDish configuration parser can be augmented with 3rd-party extensions. Every extension is implemented as a role which
will be used to build the final grammar or actions classes (see L<C<Grammar>|https://docs.raku.org/type/Grammar>). The
classes are based upon
L<C<Config::BINDish::Grammar>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar.md> and
L<C<Config::BINDish::Actions>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Actions.md>
respectively. Here is the steps C<Config::BINDish> does to build them:


The order in which the extensions are added is defined by the order and the way they're registered. The later added ones
serve as the earlier parents meaning that Raku's method call dispatching will have their methods invoked first.


There are two and a half ways to extend the parser. First is to use `is BINDish-grammar` or `is BINDish-actions` trait:


unit module Config::BINDish::Ext1;
role Grammar is BINDish-grammar {
    token value:sym<mine> {
        ...
    }
}
role Actions is BINDish-actions {
    method value:sym<mine>($/) {
        ...
    }
}


In this case the role they're applied to will be auto-registered with C<Config::BINDish>. When such extension is
contained by a module then it would be added when the module is C<use>d:


use Config::BINDish::Ext1;
use Config::BINDish::Ext2;


I<Note> that considering the order of C<use> statements, C<Ext2> will be able to override methods of C<Ext1>.


The specificifty of using the traits is that extensions declared this way will become application-wide available. So, even
if the extension module is used by a module used by the main code, the extension will be available to any instance of
C<Config::BINDish>.


B<Note:> We say that extensions registered with the traits are registered I<statically>.


The other 1.5 ways of adding the extensions are to use C<extend-grammar> and C<extend-actions> constructor arguments or
methods with the same names:


my $cfg = Config::BINDish.new: :extend-grammar(ExtG1, ExtG2), :extend-actions(ExtA1, ExtA2);
$cfg.extend-grammar(ExtG3)
    .extend-actions(ExtA3);


In this case extension roles don't need the traits applied. This way we call I<dynamic> registration.


The other specific of dynamic extensions is that they will go after the static ones. I.e. in the above examples
C<ExtG*> and C<ExtA*> will be positioned before C<Ext1> and C<Ext2> in the MRO order, prioritizing the former over the
latter ones.


Why is the above called I<1.5 ways>? Because the constructor eventually uses the C<extend-*> methods with corresponding
C<:extend-*> named attributes.


See also
L<C<Config::BINDish::Grammar>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar.md> and
L<C<Config::BINDish::Actions>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Actions.md>.


L<C<Config::BINDish::Grammar::Strictness>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar/Strictness.md> C<$.strict>


The default grammar strictness mode. See L<C<Config::BINDish::Grammar::Strictness>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar/Strictness.md> documentation for details.


These two attributes contain user-defined structure of the config file. More information about them can be found in
L<Config::BINDish::Grammar|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Grammar.md> documentation, methods C<declare-blocks> and C<declare-options>.


The final grammar and actions class versions with all registered extensions applied. Both attributes are I<lazy> and
C<clearable> in terms of L<C<AttrX::Mooish>|https://modules.raku.org/dist/AttrX::Mooish:cpan:VRURG>. It means that the
following is possible:


say $cfg.grammar.^name; # Config::BINDish::Grammar...
$cfg.extend-grammar(MyApp::GrammarMod);
$cfg.clear-grammar;     # Actually, extend-grammar already does this. This line is here to demo the concept only.
say $cfg.grammar.^name; # Config::BINDish::Grammar+{MyApp::GrammarMod}...


L<C<IO::Path>|https://docs.raku.org/type/IO::Path> C<$.file>


If C<read> method was called with C<:file<...>> argument then this attribute will hold corresponding C<IO::Path> object
for the file name.


L<C<Bool>|https://docs.raku.org/type/Bool> C<$.flat = False>


If set to C<True> then L<C<Config::BINDish::Actions>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Actions.md>
will act in flattening mode.


The top node produced by the grammar actions. I.e. it is the result of C<<$<TOP>.ast>> of the
L<C<Match>|https://docs.raku.org/type/Match> object produced by grammar's C<parse> method. For
L<C<Config::BINDish::Actions>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/Actions.md> it would be an instance of
L<C<Config::BINDish::AST>|https://github.com/vrurg/raku-Config-BINDish/blob/v0.0.1/docs/md/Config/BINDish/AST.md>.
But an extension can produce something to its taste which wouldn't be an AST whatsoever. The only requirement imposed
on the object stored by the attribute is to provide C<get> method.


This attribute C<handles> method C<get>.


This attribute stores the L<C<Match>|https://docs.raku.org/type/Match> object produced by grammar's C<parse> method.


C<extend-grammar( +@ext )>, C<extend-actions( +@ext )>


Interface to dynamically register extensions. Take a list of roles and records them as extensions. Then it clears
C<$.grammar> or C<$.actions> attributes, respectively. Both return C<self> to allow method call chaining.


Methods used by L<C<AttrX::Mooish>|https://modules.raku.org/dist/AttrX::Mooish:cpan:VRURG> to lazily initialize
C<$.grammar> and C<$.actions> attributes respectively.


C<multi method read(Config::BINDish:U: |args)>


Instantiates C<Config::BINDish> class and re-invokes C<read> method on the instance with C<args> capture.


C<multi method read(IO:D(Str:D) :$file, |args)>, C<multi method read(Str:D :$string, |args)>


BINDish

The Raku Knowledge Base


=begin React :component<HeaderCol> :id<footer>  
=begin nested :!nested
=item1 B<Language>
    =item2 L<Get started|file:../getting-started/getting-started.podlite>
    =item2 L<Why Raku?|/doc/language/faq#Why-should-I-learn-Raku-What's-so-great-about-it>
    =item2 L<Try Raku|https://glot.io/new/raku>
    =item2 L<Raku cheat sheet|https://github.com/Raku/mu/blob/master/docs/Perl6/Cheatsheet/cheatsheet.txt>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<Raku on Exercism|https://exercism.org/tracks/raku>
    =item2 L<Wikipedia|https://en.wikipedia.org/wiki/Raku_(programming_language)>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>

=end nested
=begin nested :!nested

=item1 B<L<Documentation|/doc>>
    =item2 L<Getting started, Migration guides from other languages, & Tutorials | file:../doc/introduction.podlite>
    =item2 L<Language References|file:../doc/reference.podlite>
    =item2 L<Type Reference| file:../doc/types.podlite>
    =item2 L<Miscellaneous| file:../doc/miscellaneous.podlite>
    =item2 L<FAQs (Frequently Asked Questions)|/doc/language/faq>
    =item2 L<Community|/doc/language/community>
    =item2 L<The list of all documents|file:../doc/index.podlite>

=item1 B<Resources>
    =item2 L<The Raku Guide|https://raku.guide/>
    =item2 L<Books |https://perl6book.com/>
    =item2 L<Rosetta Code | https://www.raku.org/community/rosettacode>

=end nested
=begin nested :!nested

=item1 B<Resoures>
    =item2 L<Download | file:../download/index.podlite>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>

=item1 B<Learning>
    =item2 L<The Raku Guide|https://raku.guide/>
    =item2 L<Wikibook |https://en.wikibooks.org/wiki/Raku_Programming>
    =item2 L<Books |https://perl6book.com/>
    =item2 L<Rosetta Code | https://www.raku.org/community/rosettacode>
    =item2 L<Learn Raku in Y minutes|https://learnxinyminutes.com/docs/raku/>
    =item2 L<Golfing |https://github.com/AlexDaniel/raku-golf-cheatsheet>
=end nested
=begin nested :!nested

=item1 B<Explore>
    =item2 L<Raku Blog Aggregator|https://planet.raku.org/>
    =item2 L<Rakudo Weekly|https://rakudoweekly.blog/>
    =item2 L<The Weekly Challenge |https://perlweeklychallenge.org/>
    =item2 L<Raku Advent Calendar|https://raku-advent.blog/>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>
    =item2 L<empty|#>

=end nested
=end React


=begin React :component<CookieConsent> :id<CookieConsent> :buttonCaption("Got it!")
=para
This website uses cookies for analytics.
=end React


Actions

NAME

DESCRIPTION

METHODS

`make-container(Config::BINDish::Grammar::Value:D $val)`

`enter-parent(Config::BINDish::AST::Parent:D $inner --` Config::BINDish::AST::Parent:D)>

`enter-parent(Config::BINDish::AST::Parent:U $inner, |profile --` Config::BINDish::AST::Parent:D)>

`inner-parent()`

SEE ALSO

AUTHOR

Config::BINDish v0.0.1

Authors

License

Dependencies

Test Dependencies

Provides

Documentation

NAME

DESCRIPTION

METHODS

make-container(Config::BINDish::Grammar::Value:D $val)

enter-parent(Config::BINDish::AST::Parent:D $inner -- Config::BINDish::AST::Parent:D)>

enter-parent(Config::BINDish::AST::Parent:U $inner, |profile -- Config::BINDish::AST::Parent:D)>

inner-parent()

SEE ALSO

AUTHOR

Config::BINDish v0.0.1

Authors

License

Dependencies

Test Dependencies

Provides

Documentation

`make-container(Config::BINDish::Grammar::Value:D $val)`

`enter-parent(Config::BINDish::AST::Parent:D $inner --` Config::BINDish::AST::Parent:D)>

`enter-parent(Config::BINDish::AST::Parent:U $inner, |profile --` Config::BINDish::AST::Parent:D)>

`inner-parent()`