> On 01 Apr 2017, at 01:35, Riley Testut via swift-evolution > <[email protected]> wrote: > > >> On Mar 20, 2017, at 8:07 PM, Greg Parker <[email protected]> wrote: >> >> This needs more explanation. It is allowed for a subclass to implement a >> convenience initializer that has the same signature as a superclass >> convenience initializer or a superclass designated initializer. The >> convenience-over-convenience case is not technically overriding, but it is >> misleading to say only that a convenience initializer cannot be overridden. >> Do factory initializers follow exactly the same rules here as convenience >> initializers? > > Yes, that is what I meant. For simplicity, I think the factory initializer > inheritance rules should match exactly that of convenience initializers. > >> In addition: designated initializers and convenience initializers have rules >> about which other initializers can be called from an implementation. These >> rules are intended to guarantee that the chain of designated initializers is >> called correctly. What are the precise rules for factory initializers >> calling other initializers? What are the precise rules for non-factory >> initializers calling factory initializers? > > Factory initializers can call any other initializers. Since calling > convenience initializers would still call required initializers, the chain > would be correct (unless I’m missing something). As for other initializers > calling factory initializers, my gut says this should not be allowed. Factory > initializers are supposed to initialize and return a value, whereas other > initializers implicitly assign to self. Therefore calling a factory > initializer from a self-assigning initializer wouldn’t do much, and I don’t > see any benefit to allowing this. > > >> On Mar 21, 2017, at 8:49 AM, David Rönnqvist <[email protected]> >> wrote: >> >> Forgive me if that has already been discussed in the email threads prior to >> the proposal, but what I’m missing from this proposal is a discussion of the >> problems factory initializers solve (other than the examples at the end) and >> an explanation of why factory initializers are the right solution to >> that/those problems in Swift. > > I can answer this anecdotally; when learning iOS development and Objective-C, > it was (in my opinion) hard to know whether an Objective-C class was meant to > be initialized via [[Class alloc] initWithParameters:] or [Class > classWithParameters:]. Pre-ARC this did actually have meaning, but post > ARC/iOS 5 it just seemed to be whatever the framework developer preferred > (not to mention that [Class new] was also another option…). > > When Swift combined all these forms into one common Class(parameters:) > format, this greatly reduced this cognitive load. However, as outlined in the > proposal, this meant that the factory pattern had to be moved out of the > initializers and back into class methods. Because of this, now if you want to > implement the factory pattern, you’re bringing back this same confusion from > Objective-C; the client has to remember whether your class is initialized via > standard Class(parameters:) syntax, or by calling a class method > Class.classWithParameters(). Ultimately, I don’t believe there should be a > difference between the two for the average programmer. You want an instance > of the class, so you should retrieve one by calling an initializer. They > don’t need to know or care whether the initializer is directly assigning to > self or returning a value, as long as they get the value they need.
If we want to hide the fact that a factory method is a factory method, then we need the “assign to self’ in the initializer. Introducing a ‘factory’ keyword for that purpose seem counter productive to me. Rien. > > Beyond this, however, I think the factory initializers on protocols is one of > this proposal’s biggest wins. For protocol oriented programming, it’s nice to > be apply to supply a default implementation so client’s don’t need to declare > their own type. However, if you come across a new codebase/framework, you > might not know the difference between the specific type you’re using and the > protocol itself (or even which one is which). I’ve personally encountered > this many times with Apple’s frameworks, such as UIActivityItemProvider and > UIActivityItemSource (which one is the protocol and which one is the type? > Hard to know and remember when first using them). With factory initializers > on protocol extensions, the initializer can return a private type conforming > to the protocol, so again there’s no need to worry about what is the concrete > type and what is the protocol. > > P.S. Phase 2 End Question > > I didn’t realize until today that apparently Swift 4 Phase 2 ends tomorrow. > Is this true, and does that mean this is now too late to make it into Swift 4? > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
