Generics seem too complicated as defined

[TekExplorer]

The generics side of things is honestly a bit strange to me.

I don't understand why we have positional parameters, and frankly i'm not sure why we're keeping a dynamic codable in the first place.

Why not:

class Box<T> implements SelfEncodable {
  Box(this.label, this.data);

  final String label;
  final T data;

  // static const Codable1<Box, dynamic> codable = BoxCodable();
  static Codable<Box<T>> codable<T>({Codable<T>? usingT}) => BoxCodable<T>(usingT: usingT);
  // alternatively, if we WANT the dynamic codable:
  static const codable = BoxCodable<dynamic>(); // + the extension below
  // BoxCodable.codable<Person>(usingT: Person.codable);

  @override
  void encode(Encoder encoder, {Encodable<T>? usingT}) {
    encoder.encodeKeyed()
      ..encodeString('label', label)
      ..encodeObject('data', data, using: usingT)
      ..end();
  }
}
class BoxCodable<T> extends Codable<Box<T>> {
  const BoxCodable({this.usingT});
  final Codable<T>? usingT;

  @override
  void encode(Box<T> value, Encoder encoder) {
    value.encode(encoder, usingT: usingT);
  }

  @override
  Box<T> decode(Decoder decoder) {
    final mapped = decoder.decodeMapped();
    return Box(
      mapped.decodeString('label'),
      mapped.decodeObject('data', using: usingT),
    );
  }
}

final Codable<Box<String>> boxStringCodable = Box.codable<String>();

// possibly
extension BoxCodableT on BoxCodable<dynamic> {
  Codable<Box<T>> call<T>({Codable<T>? usingT}) => BoxCodable(usingT: usingT);
}

This simplifies the weirdness with "use" and actually feels like a generic.

To be fair, I don't fully understand exactly what's happening, but it feels weirdly complicated for basic generics

[schultek]

This is already part of the proposal: https://github.com/schultek/codable/blob/main/docs/rfc.md#generics

The dynamic codable and the generic call extension.

The only difference in your code is its using named parameters instead of named ones.

[TekExplorer]

This is already part of the proposal: https://github.com/schultek/codable/blob/main/docs/rfc.md#generics

The dynamic codable and the generic call extension.

The only difference in your code is its using named parameters instead of named ones.

Maybe that's all we need? The positional parameters kinda screws with the rest. And, since they're optional, you can add or remove them almost at will.

Though it may make more sense for generic inheritance to not be SelfEncodable directly, if it gets complicated with adding and subtracting type parameters

[schultek]

There is no functional difference between positional and named params, I don't get why it would make things easier.

[TekExplorer]

There is no functional difference between positional and named params, I don't get why it would make things easier.

at the very least it means you dont have that issue where swapped generics screw with your encode function.

class Foo<A, B> implements Bar<B, A> {}

[schultek]

Ah yes that makes sense and would be a good improvement. Do you want to make a PR?

[TekExplorer]

Ah yes that makes sense and would be a good improvement. Do you want to make a PR?

I'm not sure I'll have the chance.

I'll try tonight. Poke me if I don't :)

[TekExplorer]

Hm. admittedly I'm not sure how, given the way you structured this.

I think it has to just be a pattern as opposed to this.

I honestly dont understand why any of this use stuff is necessary. if you're going to wrap it anyway, then just make it an instance field of the codable, and let call() just be a copyWith-like

I do understand the use of use on the SelfEncodable, though it's still mildly painful.

[TekExplorer]

Honestly, now that i think about it, why are we allowing a dynamic codable in that case at all?

It seems to me that it implies a default treatment, with a default value, which doesn't make sense, as there is no "default"

It may be better to let it be a static function instead of a CodableN with a use/call

SelfEncodable is a problem in this case, but there's not much we can do about that.

Honestly experamenting with it now i dont see a clean way to handle it.