rhai/doc/src/about/non-design.md

67 lines
3.0 KiB
Markdown
Raw Normal View History

2020-06-20 16:56:56 +02:00
What Rhai Isn't
===============
2020-06-20 09:57:15 +02:00
{{#include ../links.md}}
Rhai's purpose is to provide a dynamic layer over Rust code, in the same spirit of _zero cost abstractions_.
It doesn't attempt to be a new language. For example:
* No classes. Well, Rust doesn't either. On the other hand...
* No traits... so it is also not Rust. Do your Rusty stuff in Rust.
* No structures/records - define your types in Rust instead; Rhai can seamlessly work with _any Rust type_.
2020-06-25 12:07:57 +02:00
2020-06-20 09:57:15 +02:00
There is, however, a built-in [object map] type which is adequate for most uses.
2020-06-27 11:34:39 +02:00
It is possible to simulate [object-oriented programming (OOP)][OOP] by storing [function pointers]
2020-09-30 17:02:01 +02:00
or [closures] in [object map] properties, turning them into _methods_.
2020-06-20 09:57:15 +02:00
* No first-class functions - Code your functions in Rust instead, and register them with Rhai.
2020-07-26 04:07:40 +02:00
There is, however, support for simple [function pointers] to allow runtime dispatch by function name.
2020-06-25 12:07:57 +02:00
2020-06-20 09:57:15 +02:00
* No garbage collection - this should be expected, so...
2020-09-30 17:02:01 +02:00
* No first-class closures - do your closure magic in Rust instead: [turn a Rhai scripted function into a Rust closure]({{rootUrl}}/engine/call-fn.md).
2020-06-20 09:57:15 +02:00
2020-09-30 17:02:01 +02:00
There is, however, support for simulated [closures] via [currying] a [function pointer] with
captured shared variables.
2020-07-26 04:07:40 +02:00
2020-09-30 17:02:01 +02:00
* No byte-codes/JIT - Rhai has an AST-walking interpreter which will not win any speed races.
The purpose of Rhai is not to be extremely _fast_, but to make it as easy as possible to
integrate with native Rust applications.
* No formal language grammar - Rhai uses a hand-coded lexer, a hand-coded top-down recursive-descent parser
for statements and a Pratt parser for expressions.
This lack of formalism allows the parser itself to be exposed as a service in order to support
[disabling keywords/operators][disable keywords and operators], adding [custom operators],
and defining [custom syntax].
2020-06-20 09:57:15 +02:00
2020-07-26 04:07:40 +02:00
Do Not Write The Next 4D VR Game in Rhai
---------------------------------------
2020-09-30 17:02:01 +02:00
Due to this intended usage, Rhai deliberately keeps the language simple and small by omitting
advanced language features such as classes, inheritance, first-class functions, closures,
concurrency, byte-codes VM, JIT etc.
2020-06-20 09:57:15 +02:00
2020-09-30 17:02:01 +02:00
Avoid the temptation to write full-fledge application logic entirely in Rhai -
that use case is best fulfilled by more complete languages such as JavaScript or Lua.
2020-06-20 09:57:15 +02:00
2020-07-26 04:07:40 +02:00
Thin Dynamic Wrapper Layer Over Rust Code
----------------------------------------
In actual practice, it is usually best to expose a Rust API into Rhai for scripts to call.
All the core functionalities should be written in Rust, with Rhai being the dynamic _control_ layer.
2020-09-30 17:02:01 +02:00
This is similar to some dynamic languages where most of the core functionalities reside in a C/C++
standard library.
2020-07-26 04:07:40 +02:00
Another similar scenario is a web front-end driving back-end services written in a systems language.
In this case, JavaScript takes the role of Rhai while the back-end language, well... it can actually also be Rust.
Except that Rhai integrates with Rust _much_ more tightly, removing the need for interfaces such
as XHR calls and payload encoding such as JSON.