lib&contrib: add some raw and nitish in READMEs

[nit.git] / lib / serialization / README.md

diff --git a/lib/serialization/README.md b/lib/serialization/README.md
index 787f51c..3832465 100644 (file)
--- a/lib/serialization/README.md
+++ b/lib/serialization/README.md
@@ -51,6 +51,8 @@ class Partnership
        redef fun ==(o) do return o isa SELF and partner_a == o.partner_a and partner_b == o.partner_b
        redef fun hash do return partner_a.hash + 1024*partner_b.hash
 end
+class Person
+end
 ~~~
 
 ### Scope of the `serialize` annotation
@@ -64,7 +66,7 @@ end
 * A module declaration annotated with `serialize` states that all its class definitions
   and locally declared attributes are serializable.
 
-  ~~~
+  ~~~nitish
   module shared_between_clients is serialize
   ~~~
 
@@ -155,7 +157,7 @@ For this customization, the following code snippet implements
 two serialization services: `User::core_serialize_to` and
 `Deserializer::deserialize_class`.
 
-~~~
+~~~nitish
 module user_credentials
 
 # User credentials for a website
@@ -233,8 +235,8 @@ you must use implementations of `Serializer` and `Deserializer`.
 The main implementations of these services are `JsonSerializer` and `JsonDeserializer`,
 from the `json_serialization` module.
 
-~~~
-import json_serialization
+~~~nitish
+import json
 import user_credentials
 
 # Data to be serialized and deserialized
@@ -260,22 +262,12 @@ assert couple == deserialize_couple
 
 The serialization has some limitations:
 
-* Not enough classes from the standard library are supported.
-  This only requires someone to actually code the support.
-  It should not be especially hard for most classes, some can
-  simply declare the `serialize` annotation.
-
-* A limitation of the Json parser prevents deserializing from files
+* A limitation of the JSON parser prevents deserializing from files
   with more than one object.
   This could be improved in the future, but for now you should
-  serialize a single object to each filesand use different instances of
+  serialize a single object to each files and use different instances of
   serializer and deserializer each time.
 
-* The `serialize` annotation does not handle very well
-  complex constructors. This could be improved in the compiler.
-  For now, you may prefer to use `serialize` on simple classes,
-  of by using custom `Serializable`.
-
 * The serialization uses only the short name of a class, not its qualified name.
   This will cause problem when different classes using the same name.
   This could be solved partially in the compiler and the library.
@@ -283,7 +275,7 @@ The serialization has some limitations:
   the different programs sharing the serialized data.
 
 * The serialization support in the compiler need some help to
-  deal with generic types. The solution is to use `nitserial`,
+  deal with generic types. A solution is to use `nitserial`,
   the next section explores this subject.
 
 ## Dealing with generic types