> Le 21 mars 2017 à 22:09, Jonathan Hull via swift-evolution > <swift-evolution@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 ? _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
