[swift-evolution] [Proposal] Factory Initializers

[Jean-Daniel]

> Le 21 mars 2017 à 22:09, Jonathan Hull via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> There are several reasons.  It is a very common pattern in ObjC/Cocoa.  For example, they allow class clusters (and the protocol equivalent).

I don’t see that as a strong argument for factory initializers.
The only benefit from factory initializer vs the convenient initializers in Obj-C is that they avoid an autorelease access. Now that ARC let us bypass the autorelease pool completely for such call, they are not needed anymore and implementing a factory initializer using a class method is far less error prone.

> One of the Apple foundation people replied earlier in this thread that it would allow them to remove several hacks from the foundation overlays, and improve safety.
> 
> One of the ideas I am most excited about is the ability for a protocol to provide default conformances.  For example, I have an Expression protocol to represent mathematical expressions, and I have a few basic conforming structs representing constants, variables, and some basic operations.  With a factory method, I can say ‘Expression(2)’ or ‘Expression(“VarName”)’ and have it create the correct conformance.  My conforming structs can even be private, if I want this to be the only way they are created.
> 
> If I have expensive-to-create immutable objects where I am creating equivalent values all the time, I can store commonly created values in a cache and return the cached versions (instead of creating an instance).  I believe cocoa used to do this with NSNumbers before tagged pointers became a thing.
> 
> Or, I could return something which is lazily created.
> 
> Longer term (once reflection has improved), I have a proposal to allow extensible factory methods. We talked about it during the original discussion, but the gist is that there would be way to get a list of all types conforming to a protocol (or all subclasses of a class) from the compiler, and then you could use static methods to query those types until you found one which has the properties you are looking for, and then instantiate and return it.  The end result is that you have a factory initializer where new conformances (even from plug-ins) can participate and be returned when appropriate.  This proposal is a necessary first step to that.
> 
> As a concrete use-case of that extension, I have been experimenting for years with auto-creating UI to edit structured data (e.g. JSON or Plists) or objects.  This is fairly easy in ObjC, but it is only possible in Swift in a very limited way at the moment.  With the above extension and key paths, I should be able to recreate my ObjC interfaces in a nicer/swiftier way.
> 
> Those are just a few of the uses.
> 

All your point are valid use cases, but they don’t tell us why is it better to support them using a language specific construct vs using a class method (and make the designated constructor private if you want to force all user of your class to use your factory method).

Or maybe I’m missing something ?