You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### I want to use lightweight dynamic compilation. I heard that Natasha requires several tens of megabytes of memory for preheating, and the packaged size also increases. I feel it's too heavy.
9
+
10
+
Answer: The preheating of Natasha is designed for beginners, the original intention is to ignore all preparation work and directly perform dynamic compilation.However, whether it's emitting or expression tree, both require reflection-related metadata for dynamic compilation. If you have experience with emitting and expression tree programming, you will know what metadata your dynamically written functions rely on. Natasha can skip preheating and support custom metadata addition. See the following example, where the input is value and the output is Math.Floor(value/0.3):
#### Natasha method template encapsulation version
54
+
> This extension library `DotNetCore.Natasha.CSharp.Extension.MethodCreator` is encapsulated based on the original Natasha and released after version 9.0 of Natasha.
55
+
```cs
56
+
varsimpleFunc="return Math.Floor(arg1/0.3);"
57
+
.WithSimpleBuilder()
58
+
.WithMetadata(typeof(Math))
59
+
.ToFunc<double, double>();
60
+
```
61
+
62
+
The above two dynamic compilations of Natasha will not cause a memory increase of tens of megabytes, they belong to on-demand construction. At the same time, it can be seen that no matter which dynamic construction, it cannot escape the constraint of `typeof(Math)`. Natasha also supports lightweight construction, which is even more concise.
63
+
64
+
### Can I use Natasha as a rule engine?
65
+
66
+
A: The dynamic construction ability of Natasha is very powerful. It can be used as the basis for developing other libraries, which was also the original intention of developing this library. You can use Natasha to encapsulate your own rule engine.
67
+
68
+
### I don't want to compile every time, can I cache the result of the script?
69
+
70
+
A: No, caching the result needs to be done by you. Natasha follows the lightweight route. `AssemblyCSharpBuilder` is the smallest and most basic compilation unit. If you want to cache, you can implement a ConcurrentDictionary<string,Delegate/Action/Func> to cache the result.Natasha is not responsible for anything other than the compilation responsibility.
71
+
72
+
### I only want to use the using statement, but I don't want to add so many references.
73
+
74
+
A: Natasha supports only preheating using without adding references after version 9.0, and a new initialization method is added:
75
+
```cs
76
+
NatashaManagement
77
+
.GetInitializer()
78
+
.WithMemoryUsing()
79
+
//.WithRefUsing()
80
+
//.WithMemoryReference()
81
+
//.WithRefReference();
82
+
//.WithExcludeReferences((asm, @namespace) =>
83
+
//!string.IsNullOrWhiteSpace(@namespace) &&
84
+
//@namespace.StartsWith("Microsoft.VisualBasic"))
85
+
.Preheating<NatashaDomainCreator>();
86
+
```
87
+
### Can the previously created compilation units be reused?
88
+
89
+
A: Before Natasha v9.0, reuse is not recommended. After v9.0, the Api: `Reset` is introduced. This method has very detailed comments to guide and remind you of the reuse considerations you need to pay attention to.
90
+
91
+
### If you don't understand metadata and don't want to manage using, can you write reliable dynamic functional logic?
92
+
93
+
A: It's quite challenging. Even with Natasha fully preheated, it is inevitable to encounter various inconsistencies caused by complex environments and excessive use of 'using' statements.Take a simple example:
94
+
```cs
95
+
namespaceMyNamespace{
96
+
97
+
publicstaticclassFile{
98
+
99
+
}
100
+
}
101
+
```
102
+
Even with implicit 'using' enabled in VS, the code above still cannot handle the issue of ambiguous reference between 'File' in 'System.IO' and 'MyNamespace'. And sometimes, Natasha's preheating with 'using' statements may cover more extensively than that in VS, which may increase the probability of errors. This requires coding conventions to constrain developers, such as avoiding class names defined by official sources and using class name extensions, for example, using 'System.IO.File' to avoid conflicts in namespace references.
0 commit comments