dynamic nul = nullptr;
dynamic boolean = false;
- // Arrays can be initialized with brackets.
- dynamic array = { "array ", "of ", 4, " elements" };
+ // Arrays can be initialized with dynamic::array.
+ dynamic array = dynamic::array("array ", "of ", 4, " elements");
assert(array.size() == 4);
- dynamic emptyArray = {};
- assert(array.empty());
+ dynamic emptyArray = dynamic::array;
+ assert(emptyArray.empty());
// Maps from dynamics to dynamics are called objects. The
// dynamic::object constant is how you make an empty map from dynamics
You can iterate over dynamic arrays as you would over any C++ sequence container.
``` Cpp
- dynamic array = {2, 3, "foo"};
+ dynamic array = dynamic::array(2, 3, "foo");
for (auto& val : array) {
doSomethingWith(val);
// pos->first is "hello"
// pos->second is "world"
- auto pos = obj.find("no_such_key);
+ auto pos = obj.find("no_such_key");
// pos == obj.items().end()
```
// Building the same document programatically.
dynamic sonOfAJ = dynamic::object
("key", 12)
- ("key2", { false, nullptr, true, "yay" });
+ ("key2", dynamic::array(false, nullptr, true, "yay"));
// Printing. (See also folly::toPrettyJson)
auto str = folly::toJson(sonOfAJ);
### Some Design Rationale
***
-**Q. Why is there no default constructor?**
-
-This is a bit of a limitation of `std::initializer_list<>` for
-this use case. The expression `dynamic d = {}` is required by the
-standard to call the default constructor if one exists (the
-reasoning for this makes sense, since `{}` is part of the concept
-of "uniform initialization", and is intended for use with things
-like `std::vector`). It would be surprising if this expression
-didn't leave `d.isArray()` true, but on the other hand it would
-also be surprising if `dynamic d` left `d.isArray()` as true. The
-solution was just to disallow uninitialized dynamics: every
-dynamic must start out being assigned to some value (or nullptr).
+**Q. Why doesn't a dynamic string support begin(), end(), and operator[]?**
+
+The value_type of a dynamic iterator is `dynamic`, and `operator[]`
+(or the `at()` function) has to return a reference to a dynamic. If
+we wanted this to work for strings, this would mean we'd have to
+support dynamics with a character type, and moreover that the internal
+representation of strings would be such that we can hand out
+references to dynamic as accessors on individual characters. There
+are a lot of potential efficiency drawbacks with this, and it seems
+like a feature that is not needed too often in practice.
**Q. Isn't this just a poor imitation of the C# language feature?**