Fix several stale references to old package names!

README.md

@@ -15,10 +15,10 @@ The most central interfaces are the base package,
 but you'll certainly need to import additional packages to get concrete implementations into action.
 
 Roughly speaking, the core package interfaces are all about the IPLD Data Model;
-the codec packages contain functions for parsing serial data into the IPLD Data Model,
+the 'codec/*' packages contain functions for parsing serial data into the IPLD Data Model,
 and converting Data Model content back into serial formats;
-the traversal package is an example of higher-order functions on the Data Model;
-concrete 'Node' implementations ready to use can be found under 'impl/*';
+the 'traversal' package is an example of higher-order functions on the Data Model;
+concrete 'Node' implementations ready to use can be found in packages in the 'node/*' directory;
 and several additional packages contain advanced features such as IPLD Schemas.
 
 (Because the codecs, as well as higher-order features like traversals, are
@@ -28,8 +28,7 @@ if you want to write your own extensions, whether for new Node implementations
 or new codecs, or new higher-order order functions!)
 
 - `github.com/ipld/go-ipld-prime` -- imported as just `ipld` -- contains the core interfaces for IPLD.  The most important interfaces are `Node`, `NodeBuilder`, `Path`, and `Link`.
-- `github.com/ipld/go-ipld-prime/impl/free` -- imported as `ipldfree` -- provides concrete implementations of `Node` and `NodeBuilder` which work for any kind of data.
-- `github.com/ipld/go-ipld-prime/impl/cbor` -- imported as `ipldcbor` -- provides concrete implementations of `Node` and `NodeBuilder` which have some special features to accelerate certain workloads with CBOR.
+- `github.com/ipld/go-ipld-prime/node/basic` -- imported as `basicnode` -- provides concrete implementations of `Node` and `NodeBuilder` which work for any kind of data.
 - `github.com/ipld/go-ipld-prime/traversal` -- contains higher-order functions for traversing graphs of data easily.
 - `github.com/ipld/go-ipld-prime/traversal/selector` -- contains selectors, which are sort of like regexps, but for trees and graphs of IPLD data!
 - `github.com/ipld/go-ipld-prime/codec -- parent package of all the codec implementations!
@@ -37,7 +36,7 @@ or new codecs, or new higher-order order functions!)
 - `github.com/ipld/go-ipld-prime/codec/dagjson` -- implementations of marshalling and unmarshalling as JSON (a popular human readable format).
 - `github.com/ipld/go-ipld-prime/linking/cid` -- imported as `cidlink` -- provides concrete implementations of `Link` as a CID.  Also, the multicodec registry.
 - `github.com/ipld/go-ipld-prime/schema` -- contains the `schema.Type` and `schema.TypedNode` interface declarations, which represent IPLD Schema type information.
-- `github.com/ipld/go-ipld-prime/impl/typed` -- provides concrete implementations of `schema.TypedNode` which decorate a basic `Node` at runtime to have additional features described by IPLD Schemas.
+- `github.com/ipld/go-ipld-prime/node/typed` -- provides concrete implementations of `schema.TypedNode` which decorate a basic `Node` at runtime to have additional features described by IPLD Schemas.
 
 
 

node.go

@@ -39,19 +39,22 @@ package ipld
 // be more optimal for some programs than others, and changing the Node
 // (and NodeBuilder) implementations lets the programmer choose.
 //
-// For concrete implementations of Node, check out the "./impl/" folder,
+// For concrete implementations of Node, check out the "./node/" folder,
 // and the packages within it.
-// "impl/free" should probably be your first start; the Node and NodeBuilder
+// "node/basic" should probably be your first start; the Node and NodeBuilder
 // implementations in that package work for any data.
 // Other packages are optimized for specific use-cases.
 // Codegen tools can also be used to produce concrete implementations of Node;
 // these may be specific to certain data, but still conform to the Node
 // interface for interoperability and to support higher-level functions.
 //
-// Nodes may also be *typed* -- see the 'schema' and 'impl/typed' packages.
-// Typed nodes have additional constraints and behaviors (and have a
-// `.Type().Kind()` in addition to their `.ReprKind()`!), but still behave
-// as a regular Node in all the basic ways.
+// Nodes may also be *typed* -- see the 'schema' package and `schema.TypedNode`
+// interface, which extends the Node interface with additional methods.
+// Typed nodes have additional constraints and behaviors:
+// for example, they may be a "struct" and have a specific type/structure
+// to what data you can put inside them, but still behave as a regular Node
+// in all ways this interface specifies (so you can traverse typed nodes, etc,
+// without any additional special effort).
 type Node interface {
 	// ReprKind returns a value from the ReprKind enum describing what the
 	// essential serializable kind of this node is (map, list, int, etc).

node/basic/HACKME.md

@@ -14,9 +14,10 @@ This is noteworthy because in codegen, this is typically *not* the case:
 in codegen, even scalar types are boxed in a struct, such that it prevents
 casting values into those types.
 
-This casting is not a concern for ipldfree types, because
-A) we don't have any kind of validation rules to make such casting worrying; and
-B) since our types are unexported, casting is still blocked by this anyway.
+This casting is not a concern for the node implementations in this package, because
+
+- A) we don't have any kind of validation rules to make such casting worrying; and
+- B) since our types are unexported, casting is still blocked by this anyway.
 
 ### about builders for scalars