umbreon22 / novel Goto Github PK

Not sure if an adapter-first versioning would be useful. Could select a different adapter instance based on version number rather than rely on versioned logic within existing adapters for backwards compatibility.

They should be public!

i.e.
https://github.com/umbreon22/novel/blob/master/src/main/java/novel/api/types/write/pens/DataPen.java#L118

private Pen parameterizedThis() {
    return (Pen) this;
}

Could instead opt to override methods on implementation.

ex.

class SomePojo {
   private final int a;
   private final String b;
   pubic SomePojo(DataPen pen) {
       this.a = pen.ints();
       this.b = pen.strings();
   }
}

Can be used in reflective readers when no other reader exists.

I'd imagine they would perform immensely better than using reflection based Array adapters.

Rather than keep them as internal classes, I think we should expose them and allow Novel users to include them in their instance if they choose to use them.

We'll also provide something like withDefaultAdapters() to the builder that includes them by default.

Records are a bit harder to modify reflectively, so it may be easier to simply leverage the public constructor.

Should be "bools"

i.e. Iterable -> Iterable<? extends Number>

ex. with IntPen

    default IntPen ints(Stream<Integer> integers) {
        integers.forEach(this::ints);
        return this;
    }
    default IntPen ints(IntStream ints) {
        ints.forEach(this::ints);
        return this;
    }

Perhaps we should extend novel as a "Proofread" novel, where all readers/writers are proofreading? Or maybe consolidate them into one single interface.
There's no easy way to access proofreading interfaces for pens and papers as of right now without rolling with your own implemenation.

They're fine where they are now, but it might make more sense to keep them separate from the Pen interface itself. Need to revisit this with a fresh mind.

We can offer the existing TypeToken implementation as a base, but we may want to be able to change how TypeTokens are generated in the future.