GitLab

ISTM that since we're talking about raw data more so than "objects" in
any kind of Alan-Kay/sending-messages/OOP sort of way, calling it
"struct" is more accurate communication.

(It's also a lot less likely to be confusing when mentioned in the same
context as javascript, since "object" and "map" tend to be collisiony
terms there; whereas "struct" just doensn't really have any prior
associations in that community as far as I know.)
Signed-off-by: Eric Myhre <hash@exultant.us>

All of these struct definitions are horrifying similar in construction
to the same-named definitions in the typesystem package: simply ever
instance of a Type pointer is instead a TypeName string.  Despite being
unattractive, this is correct: since typesystem can have pointers and
cycles, and typedeclaration can't, this is what we end up with.
Signed-off-by: Eric Myhre <hash@exultant.us>

While fixing this it occurs to me that we could in theory also support
more than one name alias that will be mapped onto the same concrete type.
...
But Let's Not with that.  It would increase the code complexity and more
importantly, *it would be lossy to do so*.  So let's not open that can
of worms: straying into lossiness territory is far worse than whatever
other hypothetical problems one might imagine trying to solve.
Signed-off-by: Eric Myhre <hash@exultant.us>

Signed-off-by: Eric Myhre <hash@exultant.us>

...and all fields are correspondingly unexported.

We're going full immutability on almost all this stuff.  I simply can't
imagine handling and maintaining this any other way.

The typesystem.Type interface also got a few more standard methods.
I'm not sure if having a Universe backpointer is going to be useful
very often or not, but it seems reasonable enough to do; we'll
definitely *have* that information during consistency checking and
reification time, so it should turn out easy to keep it.

The validate_test.go code is now looking a bit janky.  We need
initializers for the typesystem.Type* values.  Those will be the
typedeclaration.* package... which we'll write next.

Note that I skipped any accessor methods on `Type*` objects which are
for representation details.  These might get filled in later, but I'm
gonna see how far I can get without them.  (So far, there's some
uses of the representation details in the validate method, but we've
located that in the typesystem package anyway, so that's... fine.)
Signed-off-by: Eric Myhre <hash@exultant.us>

See previous commit for more discussion of the child packages to come,
or the schema.md file in the docs dir, which describes similar.

Several large todos in comments.

Quite importantly: typed.Node is now an **interface**, not a concrete
struct itself.  The godoc comment should explain this nicely; long
story short, this is going to be relevant when we get to codegen and
other advanced form of native integration.
Signed-off-by: Eric Myhre <hash@exultant.us>

I need there to be separate packages for:

- the typed.Node interface, and any top level helpers;
- the typesystem implementation
- the typesystem *declarations* (distinct because it's what you
 construct when parsing the ast -- doens't contain pointers yet)
- and (eventually) a parser and a fmt package for the ts declarations.

And right now all those are heaped together.

Not sure where the validate method -- the thing that's actually touched
in this diff -- will end up.  Either the top level, or the typesystem
implementation package, probably.
Signed-off-by: Eric Myhre <hash@exultant.us>

This will be for the active path -- if we also follow through on the
idea of having a just-in-time checked Node wrapper, a lot of these
checks might end up duplicated.  We'll DRY that up when we get there.

Doing accumulation of errors.  Might get loud.  We can come back and
and early-halt parameters or other accumulation strategies later.

Added IsNull predicate to core Node interface.

Going to want enumerated error categories here for sure, but punting
on that until we get more examples of what all the errors *are*; then
I'll come back and tear all this 'fmt.Errorf' nonsense back out.
Signed-off-by: Eric Myhre <hash@exultant.us>

And ReprKind moves from the typed package to the ipld main package.
It's hard to get too much done without the standardization of ReprKind.

Between the Kind() and Keys() methods, it should now be possible to
perform traversals of unknown nodes.

This diff just worries about implementing all the Kind() methods.
Keys() has some additional questions to handle (namely, map ordering?).
Signed-off-by: Eric Myhre <hash@exultant.us>

Having a Name() interface method might also have been useful, but at
the moment, it's too annoying.  Maybe I'll come back to this and add a
ton of constructors for each kind of type and make all their fields
private scope, which would solve the name collision... maybe.  Later.
(This is all expected to be implementation-internal stuff in the long
run rather than anything user-facing API, so it's up for debate how
much polishing it's actually worth.  Unless that changes!)

The ReprKind method is *usually* pretty predestined based on the kind
of type in the first place, but a few cases are interesting.

... *Especially* kinded unions.  I'm a little alarmed at the break of
pattern, there.  Hopefully that doesn't manifest too much complexity
down the road.  But if it does... eh, well... nature of the beast.
Kinded unions are definitely a useful feature.
Signed-off-by: Eric Myhre <hash@exultant.us>

There's... not really much to it.
Signed-off-by: Eric Myhre <hash@exultant.us>

Signed-off-by: Eric Myhre <hash@exultant.us>

Giving a type to each, um, kind of type.

Syntax draft changed.  Bigger examples elsewhere.  May need to start
writing up more, but might not belong in this repo, either (it's not
a detail of the golang implementation alone).  Anyway, it's only for
eyecandy at present: I'm not going to start work on a parser for the
DSL any time soon; it's just something to keep in mind so it can be
evaluated against simplicity heuristics.

Struct fields are in a slice now.

Waffling on whether to call that kind "struct" vs "object".  Neither is
very satisfying.  "Struct" is suggestive of something with concrete
memory layout considerings; this is not that.  "Object" is suggestive
of something with methods and behaviors attached; this is not that.

Introduce an enum for different kinds of union.  Some of the terms here
are developed from https://github.com/ipfs/unixfs-v2/issues/20 ; the
term "keyed" is from https://github.com/polydawn/refmt/pull/30 ; and
the style "kinded" is a concept I haven't written up much about before,
but the TypeUnion.ValuesKinded field type should self-explain it.

Flip terminology from "required" to "optional".  Struct fields that are
mentioned in the schema default to being required; why else would you
have mentioned them?  Previous draft of DSL which used question marks
and exclamations points to denote these things dropped; the new hope is
that *neither* nullable nor optional will be used with enough frequency
that the sigil-heavy shorthand will turn out to be desirable.
Signed-off-by: Eric Myhre <hash@exultant.us>

The very first draft tried to get away with *one* "Kind" enumeration,
but that quickly became odd and shakey; *two* separate "Kind" enums
(one for the Data Model, one for the lower level Representation;
working terms, and mine) fits a lot better.  The latter is what we're
committing here.

Also of interest here is a proposal for a distinction between whether
fields are *required* vs *nullable*.  I'm not sure this has been done
before in any of the other systems I've examined so far; it's a concept
I think we'll want for dealing with the subtle distinction between
whether some piece of data *matches* our schema vs whether it's *valid*
within our schema.  But it's quite hypothetical; it's possible this
whole concept of "matching" will turn out a lot more complex than that.

There's a tossed out syntax for a schema DSL in a comment.  This is
utterly unscrutinized and should not be taken too seriously yet.

The example code at the bottom declaring some type system is code that
*could* be used, but is mostly for demonstration and early dev
purposes: in the long run, we *do* want to come up with a DSL, and all
the relevant grammers, parsers, and so on for using that as an
implementation-agnostic source of truth.  At that (far future) point,
this kind of code would be used internally to represent what's been
parsed out of the DSL; but users shouldn't really be writing it.
(That's a long-winded way of saying "yes, some parts of that code are
extremely not DRY and would be error prone if written manually"; and
indeed, they would, and thus the point is not to.)
Signed-off-by: Eric Myhre <hash@exultant.us>