> On 13 Apr 2017, at 06:20, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>
>> On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I want to disagree with this is strongly as possible lest it influence
>> the proposal in any way whatsoever. Just because you can solve something
>> through reflection doesn't mean you should.
>
>
> Cosigned. Reflection is really cool, but it's generally going to be the
> least-efficient, most-buggy possible way to implement a given feature.
> There's something to be said for just...writing some code. Especially when
> the computer is writing it for you.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
The computer writing it for you is good, but the compiler writing it for you is
bad. For one thing, it’s less easy to debug source code that isn’t written
anywhere.
I continue to think this proposal would be better with some kind of attribute
(“annotation” in javaspeak) to allow more principled code-generation. Or a
"property behaviour”, if that’s intended to do the same thing.
It could possibly be built-in (like @NSManaged, @objc, lazy, etc):
struct MyThing: Codable {
@coded let id: Int64
let name: String
}
This proposal is optimised for POD types where everything is serialised and
there is no danger of leaking private, disposable or otherwise non-persistable
details.
Once you want to leave a field out, you’re back to the same-old boilerplate
that every other serialisation framework faces. An attribute would help with
that.
That’s just one of the issues with this proposal. Having some way to customise
the key name is another; you could imagine the attribute could take a parameter
- e.g. @coded(“thing_id”).
I’d certainly consider supporting a better proposal, but this one is too narrow
in capabilities and imagination IMO.
- Karl_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
