README.md in jsi-0.8.0 vs README.md in jsi-0.8.1

- old
+ new

@@ -61,12 +61,16 @@ ``` So, if we construct an instance like: ```ruby -# this would usually load YAML or JSON; the schema instance is inlined for copypastability. -bill = Contact.new_jsi({"name" => "bill", "phone" => [{"location" => "home", "number" => "555"}], "nickname" => "big b"}) +bill = Contact.new_jsi( + # this would typically load JSON or YAML; the schema instance is inlined for copypastability. + {"name" => "bill", "phone" => [{"location" => "home", "number" => "555"}], "nickname" => "big b"}, + # note: bill is mutable to demonstrate setters below; the default is immutable. + mutable: true +) # => #{<JSI (Contact)> # "name" => "bill", # "phone" => #[<JSI (Contact.properties["phone"])> # #{<JSI (Contact.properties["phone"].items)> # "location" => "home", @@ -238,9 +242,13 @@ ``` ### A note on Classes The classes used to instantiate JSIs are dynamically generated subclasses of JSI::Base which include the JSI Schema Module of each schema describing the given instance. These are mostly intended to be ignored: applications aren't expected to instantiate these directly (rather, `#new_jsi` on a Schema or Schema Module is intended), and they are not intended for subclassing or method definition (applications should instead define methods on a schema's {JSI::Schema#jsi_schema_module}). + +## Mutability + +JSI instances are immutable by default. Mutable JSIs may be instantiated using the `mutable` param of `new_jsi`. Immutable JSIs are much more performant, because mutation may change what schemas apply to nodes in a document, and checking for that is costly. It is not recommended to instantiate large documents as mutable; their JSI instances become unusably slow. ## Registration In order for references across documents (generally from a `$ref` schema keyword) to resolve, JSI provides a registry (a {JSI::SchemaRegistry}) which associates URIs with schemas (or resources containing schemas). The default registry is accessible on {JSI.schema_registry}.