Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Sep 2, 2017, at 00:30, Fabian Ehrentraud > wrote: > > > Am 03.08.2017 um 02:09 schrieb Jordan Rose via swift-evolution > >: > >> David Hart recently asked on Twitter >>

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Am 03.08.2017 um 02:09 schrieb Jordan Rose via swift-evolution >: David Hart recently asked on Twitter if there was a good way to add Decodable support to somebody else's class.

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Aug 6, 2017, at 12:58 PM, Charles Srstka wrote: > >> On Aug 3, 2017, at 12:05 PM, Itai Ferber via swift-evolution >> > wrote: >> >> Thanks for putting these thoughts together, Jordan! Some additional

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Aug 3, 2017, at 12:05 PM, Itai Ferber via swift-evolution > wrote: > > Thanks for putting these thoughts together, Jordan! Some additional comments > inline. > >> On Aug 2, 2017, at 5:08 PM, Jordan Rose > >

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

To clarify a bit here — this isn’t a "privilege" so much so as a property of the design of these classes. `NSData`, `NSString`, `NSArray`, and some others, are all known as _class clusters_; the classes you know and use are essentially abstract base classes whose implementation is given in

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > > > Le 3 août 2017 à 19:10, Itai Ferber a écrit : > > > > I just mentioned this in my other email, but to point out here: the > reason this works in your case is because you

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> Le 3 août 2017 à 19:10, Itai Ferber a écrit : > > I just mentioned this in my other email, but to point out here: the reason > this works in your case is because you adopt these methods as static funcs > and can reasonably rely on subclasses of NSData, NSNumber, NSString,

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

I just mentioned this in my other email, but to point out here: the reason this works in your case is because you adopt these methods as static funcs and can reasonably rely on subclasses of NSData, NSNumber, NSString, etc. to do the right thing because of work done behind the scenes in the

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Thanks for putting these thoughts together, Jordan! Some additional comments inline. > On Aug 2, 2017, at 5:08 PM, Jordan Rose wrote: > > David Hart recently asked on Twitter > if there was a good > way to add

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Aug 2, 2017, at 10:48 PM, David Hart wrote: > > Somewhat related: I have a similar problem in a project where I need two > different Codable conformances for a type: one for coding/decoding from/to > JSON, and another one for coding/decoding from/to a database row. The

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> Le 3 août 2017 à 02:09, Jordan Rose via swift-evolution > a écrit : > > P.S. There's a reason why Decodable uses an initializer instead of a > factory-like method on the type but I can't remember what it is right now. I > think it's something to do with having

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Wrapper structs FTW. I think it's a lovely pattern that's super Swifty and really should be advertised more for solving these kinds of problems. Language-level features could also be useful for making that more usable, and the discussion about "strong" typealiases seems oriented in that

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On 3 Aug 2017, at 08:00, Slava Pestov wrote: > > >> On Aug 2, 2017, at 10:48 PM, David Hart > > wrote: >> >> Somewhat related: I have a similar problem in a project where I need two >> different Codable conformances for a

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Sent from my iPhone > On 3 Aug 2017, at 01:09, Jordan Rose via swift-evolution > wrote: > > > 'required' initializers are like methods: they may require dynamic dispatch. > That means that they get an entry in the class's dynamic dispatch table, > commonly known

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Thanks for the detailed explanation Jordan! Comment inline: > On 3 Aug 2017, at 02:08, Jordan Rose wrote: > > David Hart recently asked on Twitter > if there was a good > way to add Decodable support to somebody

[swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

David Hart recently asked on Twitter if there was a good way to add Decodable support to somebody else's class. The short answer is "no, because you don't control all the subclasses", but David already understood that and wanted to know