Am 13.04.2017 um 06:20 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:
On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
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
···
On 13 Apr 2017, at 06:20, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
On Fri, Apr 21, 2017, at 11:26 AM, Tony Parker via swift-evolution wrote:> One more thing, which we realized after I sent my original email: the
default implementation of many of the protocols needs to throw errors.
Therefore we will add enum EncodingError and enum DecodingError to the
list of new types. Those enums will have various associated values
according to what is useful debug information. To preserve the ability
for developers to present these errors to users with localized and user-
presentable messages, when these enums are cast to NSError (e as?
NSError), they will have the Cocoa error domain and a Foundation-
provided code. (This is done via an extension to the enum in
Foundation).
This is the best possible outcome for layering. Thanks to everyone
involved for reconsidering that.
Sincerely,
Zachary Waldowski
zach@waldowski.me
And all of this is only an issue if you write the conformance by hand in the first place. Usually, you won't.
Brent, given that this API is designed not just for NSKeyedArchiver-like usage, but to form the basis of serialization to and from JSON, among other network types, I really don’t think this is true. It just won’t work by default for JSON, if only because JSON has informally standardized on snake-case keys (some_key). AFAICT, this proposal has nothing to enable developers to define a key convention that automatically generates such keys. So, from my perspective, every single use of the proposed APIs that isn’t just a replacement for NSKeyedArchiver will be forced to manually implement the entire API, unless developers get lucky and somehow get a representation that fits a good Swift type exactly. That just doesn’t happen. There are so many bad JSON APIs out there that being able to easily define different keys and transforms of a JSON type to some Swift type isn’t just a convenience, it’s a requirement.
Depends on exactly what you mean by “isn’t written anywhere”... Xcode can show what a C-family file looks like post-preprocessing (although I don’t think it lets you set breakpoints or anything, so it’s only half a solution in terms of debugging). I haven’t used other IDEs enough to know if that’s a common feature. Anyway, I’m not sure that’s a road we should or even can go down, but it’s not entirely without precedent.
- Dave Sweeris
···
On Apr 15, 2017, at 9:40 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:
On 13 Apr 2017, at 06:20, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
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.