nushell/crates/nu-plugin/src
Devyn Cairns 6795ad7e33
Make custom value type handling more consistent (#12230)
[Context on
Discord](https://discord.com/channels/601130461678272522/855947301380947968/1219425984990806207)

# Description

- Rename `CustomValue::value_string()` to `type_name()` to reflect its
usage better.
- Change print behavior to always call `to_base_value()` first, to give
the custom value better control over the output.
- Change `describe --detailed` to show the type name as the subtype,
rather than trying to describe the base value.
- Change custom `Type` to use `type_name()` rather than `typetag_name()`
to make things like `PluginCustomValue` more transparent

One question: should `describe --detailed` still include a description
of the base value somewhere? I'm torn on it, it seems possibly useful
for some things (maybe sqlite databases?), but having `describe -d` not
include the custom type name anywhere felt weird. Another option would
be to add another method to `CustomValue` for info to be displayed in
`describe`, so that it can be more type-specific?

# User-Facing Changes
Everything above has implications for printing and `describe` on custom
values

# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
2024-03-19 11:09:59 +01:00
..
plugin Make custom value type handling more consistent (#12230) 2024-03-19 11:09:59 +01:00
protocol Make custom value type handling more consistent (#12230) 2024-03-19 11:09:59 +01:00
serializers MsgPack deserializer: improve handling of EOF (#12183) 2024-03-13 06:49:53 -05:00
util Allow plugins to set environment variables in their caller's scope (#12204) 2024-03-15 06:45:45 -05:00
lib.rs Allow plugins to set environment variables in their caller's scope (#12204) 2024-03-15 06:45:45 -05:00
sequence.rs Bidirectional communication and streams for plugins (#11911) 2024-02-25 16:32:50 -06:00