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

[Gwendal Roué]

> Le 4 août 2017 à 06:33, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
> 
> On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > Le 3 août 2017 à 19:10, Itai Ferber <iferber at apple.com <mailto:iferber at apple.com>> 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, etc. to do the right thing because of work done behind the scenes in the ObjC implementations of these classes (and because we’ve got established subclassing requirements on these methods — all subclasses of these classes are going to look approximately the same without doing anything crazy).
> >
> > This would not work for Codable in the general case, however, where subclasses likely need to add additional storage, properties, encoded representations, etc., without equivalent requirements, either via additional protocols or conventions.
> 
> Thaks for your explanation why a static method in a protocol is able to instantiate non final classes like NSData, NSDate, NSNumber, NSDecimalNumber, NSString, etc.
> 
> Is this "privilege" stable? Can I rely on it to be maintained over time? Or would it be a better idea to drop support for those low-level Foundation classes, because they'll eventually become regular classes without any specific support? This would not harm that much: Data, Date, String are there for a reason. NSDecimalNumber is the only one of its kind, though.
>  
> Why not Decimal? 

Because I missed it entirely when I brought my ObjC Foundation luggage with me! Thanks for the hint!

Gwendal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170804/4649b190/attachment.html>