magic.signals
17.1.7
dotnet add package magic.signals --version 17.1.7
NuGet\Install-Package magic.signals -Version 17.1.7
<PackageReference Include="magic.signals" Version="17.1.7" />
paket add magic.signals --version 17.1.7
#r "nuget: magic.signals, 17.1.7"
// Install magic.signals as a Cake Addin #addin nuget:?package=magic.signals&version=17.1.7 // Install magic.signals as a Cake Tool #tool nuget:?package=magic.signals&version=17.1.7
magic.signals - Super signals for Hyperlambda
magic.signals is a "Super Signals" implementation for .Net 8 built on top of magic.node, allowing you to invoke functions from one assembly in another assembly without having any direct references between your projects.
Active Events or Super Signals internals
Zero cross project references is made possible by always having a YALOA, allowing us to invoke methods in classes through a "magic string", which references a type in a dictionary, where the string is its key, and the types are dynamically loaded during startup of your AppDomain. Imagine the following code.
[Slot(Name = "foo.bar")]
public class FooBar : ISlot
{
public void Signal(ISignaler signaler, Node input)
{
input.Value = 42;
}
}
The above declares a "slot" for the signal [foo.bar]. In any other place in our AppDomain we can use an ISignaler
instance to Signal the above slot by using something such as the following.
/*
* This will invoke our Signal method above
*/
var args = new Node();
signaler.Signal("foo.bar", args);
/*
* The value of args is now 42.
*/
Assert.Equal(42, args.Value);
Notice that there are no shared types between the invoker and the handler, and there are no references necessary to be shared between these two assemblies. This results in an extremely loosely coupled plugin architecture, where you can dynamically add any plugin you wish into your AppDomain, by simply referencing whatever plugin assembly you wish to bring into your AppDomain, and immediately start consuming your plugin's functionality - Or dynamically loading it during runtime for that matter, resulting in that you instantly have access to its slots, without needing to create cross projects references in any ways.
This results in an extremely loosely coupled architecture of related components, where any one component can easily be exchanged with any other component, as long as it is obeying by the implicit interface of the component you're replacing. Completely eliminating "strongly typing", making interchanging components with other components equally simply in a static programming language such as the .Net CLR as providing a function object in JavaScript.
In many ways, this results in having all the advantages from a functional programming language in a static programming language, while still keeping the strongly typing around for cases where you need strongly typing - Allowing you to choose which paradigm you want to use, based upon individual use cases, and not having the language and platform dictate your choices in these regards.
The magic.signals implementation uses IServiceProvider
to instantiate your above FooBar
class when it
wants to evaluate your slot. This makes it behave as a good IoC citizen, allowing you to pass in for instance
interfaces into your constructor, and have the .Net dependency injection automatically create objects
of whatever interface your slot implementation requires.
There is also an async
version of the interface, which allows you to declare async slots, transparently
letting the runtime choose which implementation to use, depending upon whether or not it is currently in
an async
execution context or not. Below you can see how to accomplish the same as above, except this
time the slot will be invoked within an async
context.
[Slot(Name = "foo.bar")]
public class FooBar : ISlotAsync
{
public Task SignalAsync(ISignaler signaler, Node input)
{
input.Value = 42;
await Task.Yield();
}
}
It's a common practice to implements slots that recursively invokes other slots, by combining the above two constructs, into one single class. Below is an example.
[Slot(Name = "foo.bar")]
public class FooBar : ISlot, ISlotAsync
{
// Sync version.
public void Signal(ISignaler signaler, Node input)
{
input.Value = 42;
}
// Async version.
public async Task SignalAsync(ISignaler signaler, Node input)
{
input.Value = 42;
await Task.Yield();
}
}
The above simple example is probably not that useful to implement as an async
slot, but for other parts of your code,
where you for instance are accessing sockets, HTTP connections, or the file system for that matter - Creating
async slots will have huge advantages for your application's ability to scale, and handle multiple simultaneous
users and connections. The runtime will "automagically" choose the correct implementation, being synchronous or
asynchronous, depending upon which execution context the execution object currently is within.
If your slots recursively invokes other slots, by for instance invoking signaler.Signal("eval", args)
, you should
also implement the async
interface, to allow for children lambda objects to be within an async context. This has huge
advantages for your application's throughput.
Passing arguments to your slots
The Node class provides a graph object for you, allowing you to automagically pass in any arguments you wish.
Notice, the whole idea is to de-couple your assemblies, hence you shouldn't really pass in anything but native types,
such as for instance System.String
, System.DateTime
, integers, etc. However, most complex POD structures, can also
easily be represented using this Node
class.
The Node class is basically a name/value/children graph object, where the value can be any object, the name a string, and children is a list of children Nodes. In such a way, it provides a more C# friendly graph object, kind of resembling JSON, allowing you to internally within your assemblies, pass in a Node object as your parameters from the point of your signal, to the slot where you handle the signal.
The Node
POCO class again, is a bi-directional POD instance, allowing you to both pass arguments into the
slot, in addition to having the slot return values back to the caller.
If you invoke Signal
or SignalAsync
from C#, you can optionally pass in a function object that will
be executed after the signal has been executed. This is useful for cases where you're creating an async signal
invocation, but not invoking it immediately, and rather returning it as a Task
to some other parts of your
system, to ensure something occurs after the signal has been executed. Below is an example.
var args = new Node();
return signaler.SignalAsync("foo.bar", args, () => { /* ... This will happen AFTER execution of signal ... */ });
Magic Signals a DSL
A lot of the idea behind Magic Signals is that combined with magic.node,
and especially its ability to parse Hyperlambda, it becomes a very good foundation for a DSL, or a Domain Specific
programming Language implementation, allowing you to easily create your own programming languages, and keywords,
based upon Hyperlambda syntax trees. Hyperlambda in this context being the textual representation of your Node
hierarchy.
Project website for magic.signals
The source code for this repository can be found at github.com/polterguy/magic.signals, and you can provide feedback, provide bug reports, etc at the same place.
Copyright and maintenance
The projects is copyright Thomas Hansen 2023 - 2024, and professionally maintained by AINIRO.IO.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 was computed. net5.0-windows was computed. net6.0 was computed. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. |
.NET Core | netcoreapp2.0 was computed. netcoreapp2.1 was computed. netcoreapp2.2 was computed. netcoreapp3.0 was computed. netcoreapp3.1 was computed. |
.NET Standard | netstandard2.0 is compatible. netstandard2.1 was computed. |
.NET Framework | net461 was computed. net462 was computed. net463 was computed. net47 was computed. net471 was computed. net472 was computed. net48 was computed. net481 was computed. |
MonoAndroid | monoandroid was computed. |
MonoMac | monomac was computed. |
MonoTouch | monotouch was computed. |
Tizen | tizen40 was computed. tizen60 was computed. |
Xamarin.iOS | xamarinios was computed. |
Xamarin.Mac | xamarinmac was computed. |
Xamarin.TVOS | xamarintvos was computed. |
Xamarin.WatchOS | xamarinwatchos was computed. |
-
.NETStandard 2.0
- magic.node.extensions (>= 17.1.7)
- magic.signals.contracts (>= 17.1.7)
NuGet packages (5)
Showing the top 5 NuGet packages that depend on magic.signals:
Package | Downloads |
---|---|
magic.lambda
A microscopic and super dynamic scripting language and DSL for .Net Core, based upon Hyperlambda syntax, and Super Signals. This project is the Hyperlambda core implementation (keywords) for Magic. To use package go to https://polterguy.github.io |
|
magic.library
Helper project for Magic to wire up everything easily by simply adding one package, and invoking two simple methods. When using Magic, this is (probably) the only package you should actually add, since this package pulls in everything else you'll need automatically, and wires up everything sanely by default. To use package go to https://polterguy.github.io |
|
magic.lambda.threading
Threading support for Hyperlambda and Magic. To use package go to https://polterguy.github.io |
|
magic.lambda.cql
CQL data adapters for Magic and Hyperlambda. To use package go to https://polterguy.github.io |
|
magic.data.cql
CQL data adapters for Magic to store files and folders, etc. To use package go to https://polterguy.github.io |
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last updated |
---|---|---|
17.1.7 | 513 | 1/12/2024 |
17.1.6 | 435 | 1/11/2024 |
17.1.5 | 526 | 1/5/2024 |
17.0.1 | 531 | 1/1/2024 |
17.0.0 | 796 | 12/14/2023 |
16.11.5 | 844 | 11/12/2023 |
16.9.0 | 812 | 10/9/2023 |
16.7.0 | 1,199 | 7/11/2023 |
16.4.1 | 1,130 | 7/2/2023 |
16.4.0 | 1,034 | 6/22/2023 |
16.3.1 | 994 | 6/6/2023 |
16.3.0 | 1,005 | 5/28/2023 |
16.1.9 | 1,353 | 4/30/2023 |
15.10.11 | 1,172 | 4/13/2023 |
15.9.1 | 1,390 | 3/26/2023 |
15.9.0 | 1,270 | 3/24/2023 |
15.8.2 | 1,307 | 3/20/2023 |
15.7.0 | 1,251 | 3/6/2023 |
15.5.0 | 2,660 | 1/28/2023 |
15.2.0 | 1,912 | 1/18/2023 |
15.1.0 | 2,332 | 12/28/2022 |
14.5.7 | 1,879 | 12/13/2022 |
14.5.5 | 2,028 | 12/6/2022 |
14.5.1 | 1,970 | 11/23/2022 |
14.5.0 | 1,925 | 11/18/2022 |
14.4.5 | 2,264 | 10/22/2022 |
14.4.1 | 2,269 | 10/22/2022 |
14.4.0 | 2,130 | 10/17/2022 |
14.3.1 | 3,469 | 9/12/2022 |
14.3.0 | 2,156 | 9/10/2022 |
14.1.3 | 2,460 | 8/7/2022 |
14.1.2 | 2,246 | 8/7/2022 |
14.1.1 | 2,152 | 8/7/2022 |
14.0.14 | 2,228 | 7/26/2022 |
14.0.12 | 2,233 | 7/24/2022 |
14.0.11 | 2,187 | 7/23/2022 |
14.0.10 | 2,142 | 7/23/2022 |
14.0.9 | 2,160 | 7/23/2022 |
14.0.8 | 2,290 | 7/17/2022 |
14.0.5 | 2,384 | 7/11/2022 |
14.0.4 | 2,334 | 7/6/2022 |
14.0.3 | 2,314 | 7/2/2022 |
14.0.2 | 2,240 | 7/2/2022 |
14.0.0 | 2,429 | 6/25/2022 |
13.4.0 | 3,671 | 5/31/2022 |
13.3.4 | 2,973 | 5/9/2022 |
13.3.0 | 2,845 | 5/1/2022 |
13.2.0 | 2,807 | 4/21/2022 |
13.1.0 | 2,616 | 4/7/2022 |
13.0.0 | 2,292 | 4/5/2022 |
11.0.5 | 3,056 | 3/2/2022 |
11.0.4 | 2,395 | 2/22/2022 |
11.0.3 | 2,411 | 2/9/2022 |
11.0.2 | 2,405 | 2/6/2022 |
11.0.1 | 501 | 2/5/2022 |
11.0.0 | 2,349 | 2/5/2022 |
10.0.21 | 2,939 | 1/28/2022 |
10.0.20 | 2,354 | 1/27/2022 |
10.0.19 | 2,325 | 1/23/2022 |
10.0.18 | 1,776 | 1/17/2022 |
10.0.15 | 2,458 | 12/31/2021 |
10.0.14 | 1,275 | 12/28/2021 |
10.0.7 | 2,209 | 12/22/2021 |
10.0.5 | 1,371 | 12/18/2021 |
9.9.9 | 1,756 | 11/29/2021 |
9.9.3 | 1,952 | 11/9/2021 |
9.9.2 | 1,721 | 11/4/2021 |
9.9.0 | 2,004 | 10/30/2021 |
9.8.9 | 1,794 | 10/29/2021 |
9.8.7 | 1,758 | 10/27/2021 |
9.8.6 | 1,743 | 10/27/2021 |
9.8.5 | 1,789 | 10/26/2021 |
9.8.0 | 2,671 | 10/20/2021 |
9.7.9 | 567 | 10/19/2021 |
9.7.5 | 1,507 | 10/14/2021 |
9.7.0 | 874 | 10/9/2021 |
9.6.6 | 1,225 | 8/14/2021 |
9.2.0 | 6,413 | 5/26/2021 |
9.1.4 | 1,298 | 4/21/2021 |
9.1.0 | 1,077 | 4/14/2021 |
9.0.0 | 980 | 4/5/2021 |
8.9.9 | 1,239 | 3/30/2021 |
8.9.3 | 1,569 | 3/19/2021 |
8.9.2 | 1,051 | 1/29/2021 |
8.9.1 | 1,121 | 1/24/2021 |
8.9.0 | 1,218 | 1/22/2021 |
8.6.9 | 3,290 | 11/8/2020 |
8.6.6 | 1,990 | 11/2/2020 |
8.6.0 | 4,236 | 10/28/2020 |
8.5.0 | 2,094 | 10/23/2020 |
8.4.0 | 5,888 | 10/13/2020 |
8.3.1 | 2,771 | 10/5/2020 |
8.3.0 | 1,315 | 10/3/2020 |
8.2.2 | 2,089 | 9/26/2020 |
8.2.1 | 1,413 | 9/25/2020 |
8.2.0 | 1,353 | 9/25/2020 |
8.1.17 | 7,314 | 9/13/2020 |
8.1.16 | 690 | 9/13/2020 |
8.1.15 | 2,052 | 9/12/2020 |
8.1.11 | 2,617 | 9/11/2020 |
8.1.10 | 1,666 | 9/6/2020 |
8.1.9 | 1,558 | 9/3/2020 |
8.1.8 | 1,517 | 9/2/2020 |
8.1.7 | 1,231 | 8/28/2020 |
8.1.4 | 1,247 | 8/25/2020 |
8.1.3 | 1,310 | 8/18/2020 |
8.1.2 | 1,251 | 8/16/2020 |
8.1.1 | 1,299 | 8/15/2020 |
8.1.0 | 556 | 8/15/2020 |
8.0.1 | 2,741 | 8/7/2020 |
8.0.0 | 1,260 | 8/7/2020 |
7.0.1 | 516 | 8/7/2020 |
7.0.0 | 1,999 | 6/28/2020 |
5.0.0 | 7,683 | 2/25/2020 |
4.0.4 | 8,058 | 1/27/2020 |
4.0.3 | 1,301 | 1/27/2020 |
4.0.2 | 1,385 | 1/16/2020 |
4.0.1 | 1,403 | 1/11/2020 |
4.0.0 | 1,441 | 1/5/2020 |
3.1.0 | 6,494 | 11/10/2019 |
3.0.0 | 3,996 | 10/23/2019 |
2.0.1 | 8,365 | 10/15/2019 |
2.0.0 | 1,701 | 10/13/2019 |
1.2.0 | 1,438 | 10/11/2019 |
1.1.9 | 1,312 | 10/10/2019 |
1.1.8 | 647 | 10/10/2019 |
1.1.7 | 7,112 | 10/9/2019 |
1.1.6 | 3,583 | 10/7/2019 |
1.1.5 | 8,516 | 10/6/2019 |
1.1.3 | 6,831 | 10/6/2019 |
1.1.2 | 5,762 | 10/5/2019 |
1.1.1 | 569 | 10/5/2019 |
1.1.0 | 590 | 10/5/2019 |