- 20 Jul, 2019 4 commits
-
-
Eric Myhre authored
A bit fun; wish there was a way to compress that block of ifdefs about optional vs nullable stuff, but so far nothing clearer has emerged. Added ErrIteratorOverread while at it. Should refactoring other node types to use it too, I suppose. But perhaps we'll just accumlate those todos for a while, since there's already one other error refactor with a chain of blocks in front of it.
-
Eric Myhre authored
The comment in the ipld.Node type about IsUndefined has been there quite a while; today we're finally using it. With this set of changes, the generated code for structs now compiles successfully again: the Undef and Null thunks are both used there.
-
Eric Myhre authored
The latter isn't used yet; that's not the main goal of this branch (and I think I'd rather do the refactor to use ipld.ErrNotExists after moving the PathSegment types from the selector package into the root... which in turn I'm not going to do while some of the other current work on Selectors is in progress in other branches. So! Latur.); I just wanted it around for documentation and clarity of intent. This also adds a couple of other dummy references to the 'typed' package. I know keeping a set of packages-used-in-this-file is a common step in the development of codegen systems targetting golang, but I'm going to try to avoid it until the need is really forced.
-
Eric Myhre authored
Generates the struct itself (including the variations of pointers and/or extra fields necessary), There are several major TODOs outstanding; and the generated code doesn't *quite* compile due to several missing references, namely: - ipld.ErrNoSuchField - ipld.Nil - ipld.Undefined The other issues remaining: - The reason ErrNoSuchField is missing is because it needs to be decided where an error like that should go. Is it meaningfully distinct from a general "key absent" error, like a map can return? If it is indeed a distinct thing, does it go in the schema package, or will that just make things annoying until the end of time since every occurence-site-sibling error is in the ipld main package? - We need to think about typed nil / typed undefined. I suspect they are an idea to be avoided (but doing so means using the NodeBuilder() method on the nil or undefined values from a struct will *not* "DTRT", which may be problematic; this can in turn be avoided by "knowing" you're working on a typed node, but, erm. It turns into a question of which of these things is less annoying). - We'll need to backtrack up to the main ipld.Node interface and add that 'IsUndefined() bool' method now! (Or, take a radical approach of using a magic const for that. But... no, that doesn't sound fun.) - Haven't even touched the NodeBuilder yet. (And the typeGenerator interface needs to have those bits broken down, as well, so that we can do good stuff with error path codesharing as with funcs for Node.) - Haven't filled in MapIterator. But that's probably just easy chug. Lots to do, in short. I just need a checkpoint. Note how we've had this on the clipboard for a while already, heh -- the info_test.go file and TestUnderstandingStructMemoryLayout have been aimed at this; notice how any extra bool fields are generated at the bottom of the emitted struct. Many yaks have been shaved in the meanwhile, and yet look at how many we have to go. Isn't this fun? Signed-off-by: Eric Myhre <hash@exultant.us>
-
- 15 Jul, 2019 1 commit
-
-
Eric Myhre authored
I'm solving the decorum problem by making "temporary" builder methods for the schema.Type values as necessary. This will allow the gengo package to use them freely for now. When we're done with all this, I want to restrict building of schema.Type values to a single method in the schema package which takes the "ast" types -- the ones we're hoping to codegen (!) -- and do lots of checks and cross-linking; the temporary builder methods will do *none*, and *of course* they can't take the "ast" types yet since they don't exist yet. Boom, cycle broken. Also: fix generateStringKind from taking a TypeName redundantly.
-