Updated docs

.github/workflows/docs.yml

@@ -21,7 +21,7 @@ jobs:
           host: ${{ secrets.DOCS_FTP_HOST }}
           username: ${{ secrets.DOCS_FTP_USER }}
           password: ${{ secrets.DOCS_FTP_PASSWORD }}
-          remote_folder: stack_runner
+          remote_folder: invokator
           # The local folder location
           local_folder: build/docs/
           # Remove existing files inside FTP remote folder

docs/1_callable_list.md

@@ -11,44 +11,44 @@ A **callable** is something that can be executed directly or after being interpr
 
 Even though callable collections may have different purposes (middleware, events etc), a collection is defined in a single way. 
 
-Below it's an example for a stack designed to run as a pipeline that process a piece of text
+Below it's an example for a collection designed to run as a pipeline that process a piece of text
 
 ```php
 use Sirius\Invokator\CallableCollection;
 
 $callables = new CallableCollection();
 
-// add a regular function to the stack
+// add a regular function to the collection
 $callables->add('trim');
 
 // add an anonymous function
 $callables->add(function($str) {
    return 'hello ' . $str;
 });
 
-// add a static method to the stack
+// add a static method to the collection
 $callables->add('Str::toUpper');
 
-// add an object method to the stack,
+// add an object method to the collection,
 // object to be retrieved at runtime from the container
 // the callable also has a priority of -100
 $callables->add('SlackChannel@send', -100);
 
-// add an object method to the stack
+// add an object method to the collection
 // with a specific priority to be executed
 // before the callable that was registered above 
 $callables->add([$logger, 'info'], -3);
 ```
 
 #### Callable priority
 
-By default, all callables in a stack have priority **zero** and callables with the same priority are executed in the order they are added to the stack.
+By default, all callables in a collection have priority **zero** and callables with the same priority are executed in the order they are added to the collection.
 
 A callable with a higher priority will be executed before a callable with a lower priority.
 
 ## Executing a collection of callables
 
-The `Sirius\Invokator` library comes with a few **stack processors** which are act as stack registries/repositories and stack executors.
+The `Sirius\Invokator` library comes with a few **collection processors** which are act as collection registries/repositories and collection executors.
 
 ```php
 use Sirius\Invokator\Processors\PipelineProcessor;
@@ -59,15 +59,15 @@ use Sirius\Invokator\Invoker;
 $invoker = new Invoker($yourChoiceOfDependencyInjectionContainer);
 $processor = new PipelineProcessor($invoker);
 
-// execute the $stack created above as a pipeline with one parameter
-$processor->processCollection($stack, ' world '); 
+// execute the collection created above as a pipeline with one parameter
+$processor->processCollection($callables, ' world '); 
 
 // this will
 // 1. create string `HELLO WORLD`,
 // 2. Write an info message to the logger
 // 3. send it to a SlackChannel
 ```
 
-Each type of stack processor has its own quirks that you can learn on the next page.
+Each type of callables processor has its own quirks that you can learn on the next page.
 
 [Next: The callable_processors](2_callable_processors.md)

docs/2_1_simple_collection.md

@@ -8,7 +8,7 @@ This processor has the following characteristics:
 1. All the parameters are passed down to each of the callables. This means all the callables should have the same signature (although this restriction can be by-passed with **modifiers**)
 2. The values returned by the callables are ignored
 
-#### Use case: Reporting/logging stack
+#### Use case: Reporting/logging
 
 ```php
 use Sirius\Invokator\Invoker;

docs/2_3_event_dispatcher.md

@@ -49,7 +49,7 @@ $dispatcher->dispatch(new EventWithName());
 
 ### Stoppable events
 
-If you want some events to be able to stop the execution of the rest of the callables in the stack you can add the `Stoppable` trait to your event classes
+If you want some events to be able to stop the execution of the rest of the callables in the collection you can add the `Stoppable` trait to your event classes
 
 ```php
 use Sirius\Invokator\Event\Stoppable;

docs/2_3_middlewares.md

@@ -6,7 +6,7 @@ title: Middlewares
 
 This processor has the following characteristics:
 1. All the parameters are passed down to each of the callables as which means all the callables should have the same signature (although this restriction can be by-passed with **modifiers**)
-2. The second to the last callables receive a `$next` as their last parameter which is a callable that continues the calls from the stack
+2. The second to the last callables receive a `$next` as their last parameter which is a callable that continues the calls from the collection
 3. Each callable may call `$next` or not
 
 #### Use case

docs/2_4_wordpress_actions.md

@@ -4,7 +4,7 @@ title: Actions a la Wordpress
 
 # Actions (a la Wordpress)
 
-This processor is similar to the "Simple stack processor" with the difference that you also have to specify a limit for the arguments passed to each callable.
+This processor is similar to the "Simple callables processor" with the difference that you also have to specify a limit for the arguments passed to each callable.
 
 This means that the callables do not have to have the same signature as for the SimpleCallables processor. This processor is just a convenience as the same result could be been achieved using the ['limit_arguments' modifier](4_callable_modifiers.md)
 
@@ -26,7 +26,7 @@ $processor->process('save_post', $postID, $wpPost, $update);
 
 **Attention!** The processor's `get()` and `add()` method return the Stack object, so you can't chain callables with arguments limit. For example the code below doesn't work as you might expect
 ```php
-$processor->add('save_post', 'validate_taxonomies', 0, 2) // this returns the stack
+$processor->add('save_post', 'validate_taxonomies', 0, 2) // this returns the collection
           ->add('validate_acf_fields', 0, 2); // this won't place a limit on the arguments for the 'validate_acf_fields' function
 ```
 

docs/2_5_wordpress_filters.md

@@ -26,8 +26,8 @@ $processor->process('the_title', $postTitle, $postID);
 **Attention!** The processor's `get()` and `add()` method return the Stack object, so you can't chain callables with arguments limit. For example the code below doesn't work as you might expect
 
 ```php
-$processor->add('the_title', 'add_category_name', 0, 2) // this returns the stack
-        ->add('add_site_name', 0, 2) // this won't place a limit on the arguments for the 'add_site_name' function
+$processor->add('the_title', 'add_category_name', 0, 2) // this returns the collection
+          ->add('add_site_name', 0, 2) // this won't place a limit on the arguments for the 'add_site_name' function
 ```
 
 [Next: Custom callable processors](2_6_custom_processors.md)

docs/2_6_custom_processors.md

@@ -4,7 +4,7 @@ title: Custom callable processors
 
 # Custom callables processor
 
-You can easily build your own custom processor by extending the `SimpleCallablesProcessor` or starting from scratch as the API for a stack processor is very simple. 
+You can easily build your own custom processor by extending the `SimpleCallablesProcessor` or starting from scratch as the API for a callables processor is very simple. 
 
 If you extend the `SimpleCallablesProcessor` you only need to implement the `processCollection()` method.
 

docs/2_callable_processors.md

@@ -5,10 +5,10 @@ title: What are callable processors in Sirius\Invokator?
 # The callable processors
 
 Callable processors are objects that have 3 objectives:
-1. To act as a registry for stacks via `$processor->get('stack_identifier')`
-2. To simplify adding callbacks to stacks via `$processor->add('stack_identifier', $callable, $priority)` which is syntactic sugar for `$processor->get('stack_identifier')->add($callable, $priority)`
-3. To process stacks stored in the registry via `$processor->process('stack_identifier', $param_1, $param_2)`
-4. To process stacks constructed separately via `$processor->processCollection($previouslyConstructedStack, $param_1, $param_2)` 
+1. To act as a registry for collections via `$processor->get('callables_identifier')`
+2. To simplify adding callbacks to collections via `$processor->add('callables_identifier', $callable, $priority)` which is syntactic sugar for `$processor->get('callables_identifier')->add($callable, $priority)`
+3. To process collections stored in the registry via `$processor->process('callables_identifier', $param_1, $param_2)`
+4. To process callable collections constructed separately via `$processor->processCollection($previouslyConstructedCollection, $param_1, $param_2)` 
 
 The processors depend on the [invoker](3_the_invoker.md) to actually execute the callbacks.
 

docs/3_callable_modifiers.md

@@ -4,17 +4,17 @@ title: What callable modifiers in Sirius\Invokator?
 
 # Callable modifiers
 
-Callable modifiers are invokable classes that alter, at runtime, how the callables from a stack are actually being executed. 
+Callable modifiers are invokable classes that alter, at runtime, how the callables from a collection are actually being executed. 
 
-Since a stack is composed of callables, the callable modifiers are actually callables as they implement the `__invoke()` method.
+Since a collection is composed of callables, the callable modifiers are actually callables as they implement the `__invoke()` method.
 
 The modifiers are composable which means you can wrap them one on top of another.
 
-The `Sirius\Invokator` library comes with a bunch of modifiers that allow you to simplify how you compose your stack. The examples use function that create the actual modifiers.
+The `Sirius\Invokator` library comes with a bunch of modifiers that allow you to simplify how you compose your collection. The examples use function that create the actual modifiers.
 
 ## The "limit arguments" modifier
 
-This modifier will limit the number of arguments passed to the callables. If your stack starts the execution with 5 arguments and the signature of a callable has only one parameter you have to use the `LimitArguments` modifier
+This modifier will limit the number of arguments passed to the callables. If your collection starts the execution with 5 arguments and the signature of a callable has only one parameter you have to use the `LimitArguments` modifier
 
 ```php
 use function Sirius\Invokator\limit_arguments;
@@ -24,20 +24,20 @@ use Sirius\Invokator\Processors\SimpleStackProcessor;
 $invoker = new Invoker($psr11Container);
 $processor = new SimpleStackProcessor($invoker);
 
-$processor->get('stack')
-        ->add(limit_arguments(function($param_1, $param2) {
-            return 'something'
-        }, 2))
-        ->add(limit_arguments('Service@method', 1));
+$processor->get('collection')
+          ->add(limit_arguments(function($param_1, $param2) {
+              return 'something'
+          }, 2))
+          ->add(limit_arguments('Service@method', 1));
 
-$processor->process('stack', $param_1, $param_2, $param_3, $param_4);
+$processor->process('collection', $param_1, $param_2, $param_3, $param_4);
 ```
 
 This modifier is used by the [actions processor](2_4_wordpress_actions.md) and the [filters processor](2_5_wordpress_filters.md)
 
 ## The "once" modifier
 
-This modifier will ensure that a callable from a stack is executed only once, even though the stack might be processed multiple times.
+This modifier will ensure that a callable from a collection is executed only once, even though the collection might be processed multiple times.
 
 It is useful for an events system where you want a particular listener to be executed only once. 
 
@@ -62,27 +62,27 @@ This can be used to override how the callable is actually being executed by pass
 
 ```php
 use function Sirius\Invokator\wrap;
-$processor->get('stack')
-        ->add(wrap('Service@method', function(callable $callable) use ($param_3, $param_4) {
-            return $callable($param_3, $param_4);
-        }, 2));
+$processor->get('collection')
+          ->add(wrap('Service@method', function(callable $callable) use ($param_3, $param_4) {
+              return $callable($param_3, $param_4);
+          }, 2));
 
-$processor->process('stack', $param_1, $param_2);
+$processor->process('collection', $param_1, $param_2);
 // the `Service@method` function will actually receive $param_3 and $param_4 as arguments instead of $param_1 and $param_2
 ```
 
 ## The "with arguments" modifier
 
-This modifier can be used when you have a callable that has a specific signature, and you don't want to change its signature nor do you want to wrap it inside an anonymous function (eg: because you want to serialize the stack)
+This modifier can be used when you have a callable that has a specific signature, and you don't want to change its signature nor do you want to wrap it inside an anonymous function (eg: because you want to serialize the collection)
 
 ```php
 use function Sirius\Invokator\with_arguments;
 use function Sirius\Invokator\ref;
 use function Sirius\Invokator\arg;
-$processor->get('stack')
+$processor->get('collection')
           ->add(with_arguments('Service@method', [arg(0), 'value', ref('SomeClass'), arg(1)]);
 
-$processor->process('stack', $param_1, $param_2);
+$processor->process('collection', $param_1, $param_2);
 
 // This is the same as calling Service@method($param_1, 'value', $container->get('SomeClass'), $param_2)
 ```

docs/couscous.yml

@@ -18,7 +18,7 @@ gacode: UA-535999-18
 
 projectName: Sirius\Invokator
 title: Sirius\Invokator
-subTitle: Implementation of various stack patterns (pipelines, middleware, events)
+subTitle: Implementation of various callables patterns (pipelines, middleware, events)
 
 # The left menu bar
 menu:
@@ -38,14 +38,14 @@ menu:
                 getting_started:
                     text: Introduction
                     relativeUrl:
-                stack:
-                    text: The callable stack
+                callable_collection:
+                    text: The callable collection
                     relativeUrl: 1_callable_collection.html
                 callable_processors:
-                    text: The stack processors
+                    text: The callable processors
                     relativeUrl: 2_callable_processors.html
-                simple_stacks:
-                    text: "- Simple stacks"
+                simple_callection:
+                    text: "- Simple collection"
                     relativeUrl: 2_1_simple_collection.html
                 pipelines:
                     text: "- Pipelines"
@@ -62,7 +62,7 @@ menu:
                 filters:
                     text: "- Filters a la Wordpress"
                     relativeUrl: 2_5_wordpress_filters.html
-                custom_stacks:
+                custom_processor:
                     text: "- Custom processors"
                     relativeUrl: 2_6_custom_processors.html
                 modifiers:

docs/index.md

@@ -20,13 +20,13 @@ Sirius Invokator is a library that implements various patterns that execute a li
 All of the above patterns have in common that they are actually a list of callables that have to be executed in different ways.
 
 In the case of **middlewares**, the starting parameter (a HTTP request) is passed from one callable to the next, each
-callable having the option to terminate with a result or call the next callable in the stack.
+callable having the option to terminate with a result or call the next callable in the collection.
 
 In the case of **pipelines**, the result of each callable is passed to the next callable and the last callable will return the result of the pipeline. 
 
 The Wordpress' **filter hooks** work similarly to pipelines with the difference that there is a "starting value" which can be modified by the callables and all the parameters are being passed to all the callables.
 
-In the case of **events**, an `event` object is passed through each callable in the stack and each callable is independent (it doesn't receive the result from the previous item in the stack). 
+In the case of **events**, an `event` object is passed through each callable in the collection, and each callable is independent (it doesn't receive the result from the previous item in the stack). 
 
 The Wordpress' **action hooks** are similar to events as the callables are not influenced by each other
 

readme.md

@@ -47,7 +47,7 @@ $processor->process($stack, "  hello world  "); // returns `HELLO WORLD!!!`
 
 ## Where to next?
 
-- [documentation](https://sirius.ro/php/sirius/stack_runner/)
+- [documentation](https://sirius.ro/php/sirius/invokator/)
 - [changelog](CHANGELOG.md)
 
 ## Todo