Strictly typed form row

[tp]

Hi,

really liking the ease and clarity of most his project :-)

While using protocols is great in principle, in practice a lot of the rows are ConcreteFormRow instances and therefore not super strictly type (for example Action = (AnyObject?) -> Void).

Would you be open to discuss more specific row types?

They would probably just end up being FormRow<T>, but then allow for event stricter code.

[fcanas]

Thanks for your interest!

I'm definitely open to revamping the types. I started this project before I really internalized swift's type system the power and purpose of protocols.

The part of this library I like the most is the general shape of the interface, declaratively creating a form, compliance validations... Everything under the hood has a lot of room for improvement.

I erred on the side of more flexibility when I started and that over-complicated things. I think it's time to restrict the interface, make it clean and useful, and maybe reintroduce flexibility as needed.

[fcanas]

@tp I'm interested in seeing a brief proposal :eyeglasses: of how you think this should be accomplished.

Or maybe my break-out of TextEntryFormRow :memo: is the kind of design you mean? In which case, :confetti_ball: :balloon: I'd be interested in seeing what additional types you'd like to see broken out, or how to improve those interfaces further.

[tp]

I had a stab yesterday at trying new protocols that would allow for strictly typed rows, but I was not able to define a protocol with generic types, that classes could implement as DecimalRow: FormRow<Double> or EmailRow: FormRow<String>`.

Maybe my thinking was wrong and not aligned with Swift or it is not yet possible in 1.2.

Definitely need to look further into this.

[fcanas]

I think the trouble is going to be that it can't be a generic row with heterogenous associated types, while also keeping a strongly-typed collection of those rows :disappointed:

I've considered using an enum with associated types, but then that really cuts down on extensibility from outside the library.

I think we'll need to tinker with possible structures to see if we can come up with anything.