> Le 4 août 2017 à 06:33, Xiaodi Wu <xiaodi...@gmail.com> a écrit : > > On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Le 3 août 2017 à 19:10, Itai Ferber <ifer...@apple.com > > <mailto:ifer...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
