<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">To clarify a bit here — this isn’t a "privilege" so much so as a property of the design of these classes.<br>
<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSData</code>, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSString</code>, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSArray</code>, and some others, are all known as <em>class clusters</em>; the classes you know and use are essentially abstract base classes whose implementation is given in private concrete subclasses that specialize based on usage. These classes are essentially an abstract interface for subclasses to follow. You can take a look at the <a href="https://developer.apple.com/documentation/foundation/nsarray#1651549" style="color:#3983C4">subclassing notes for <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSArray</code></a>, for instance, to see the guidelines offered for subclassing such a base class.</p>
<p dir="auto">The reason you can relatively safely offer <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">static</code> extensions on these types is that it’s reasonably rare to need to subclass them, and at that, even rarer to offer any interface <em>besides</em> what’s given by the base class. You can rely on the, say, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSString</code> interface to access all functionality needed to represent a string. If I were to subclass <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSString</code> with totally different properties, though, your <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">static</code> extension might not take that into account.</p>
<p dir="auto">Not all types you list here are class clusters, BTW, but they largely fall into the same category of "never really subclassed". There’s no real need for anyone to subclass <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSDate</code> or <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NSDecimalNumber</code> (since they’re pretty low-level structural types), so this should apply to those as well.</p>
<p dir="auto">In general, this property applies to all types like this which are rarely subclassed. In Swift, types like this might fall under a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">final class</code> designation, though in Objective-C it’s more by convention/lack of need than by strict enforcement. There’s a reason we offer some of these as <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">struct</code>s in Swift (e.g. <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Date</code>, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Decimal</code>, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Data</code>, etc.).</p>
<p dir="auto">On 3 Aug 2017, at 21:03, Gwendal Roué wrote:</p>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999">
<p dir="auto">Le 3 août 2017 à 19:10, Itai Ferber <a href="mailto:iferber@apple.com" style="color:#999">iferber@apple.com</a> a écrit :</p>
<p dir="auto">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).</p>
<p dir="auto">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.</p>
</blockquote>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">Gwendal</p>
</blockquote>
</div>
</div>
</body>
</html>