1. 22 Aug, 2021 1 commit
  2. 29 Jul, 2021 1 commit
  3. 25 Dec, 2020 1 commit
    • Daniel Martí's avatar
      all: rename schema.Kind to TypeKind, ipld.ReprKind to Kind · 2d7d25c4
      Daniel Martí authored
      As discussed on the issue thread, ipld.Kind and schema.TypeKind are more
      intuitive, closer to the spec wording, and just generally better in the
      long run.
      
      The changes are almost entirely automated via the commands below. Very
      minor changes were needed in some of the generators, and then gofmt.
      
      	sed -ri 's/\<Kind\(\)/TypeKind()/g' **/*.go
      	git checkout fluent # since it uses reflect.Value.Kind
      
      	sed -ri 's/\<Kind_/TypeKind_/g' **/*.go
      	sed -i 's/\<Kind\>/TypeKind/g' **/*.go
      	sed -i 's/ReprKind/Kind/g' **/*.go
      
      Plus manually undoing a few renames, as per Eric's review.
      
      Fixes #94.
      2d7d25c4
  4. 29 Jun, 2020 2 commits
  5. 26 Jun, 2020 2 commits
  6. 26 Apr, 2020 1 commit
    • Eric Myhre's avatar
      All the other scalars. · 2f7df511
      Eric Myhre authored
      It's possible these could be dedup'd... a lot, honestly.  I'm wondering
      if they actually need a discrete type per kind at all, anymore; it's
      seeming much more tractable to try to turn that into a "no" after all
      the other successful work this morning abstracting things.
      
      But I have some other things I want to ship and do demos and prototypes
      of that's a lot more interesting than shaving more lines off today.
      So just gonna roll with the existing convention and stamp these out.
      Might deserve a revisit in the future.  Might not.  Time will tell.
      2f7df511