Any hopes for it in future? On 4 June 2017 at 20:40, Xiaodi Wu <[email protected]> wrote:
> No. > > > > On Sun, Jun 4, 2017 at 10:07 Pranshu Goyal via swift-evolution < > [email protected]> wrote: > >> Is this proposal in the pipeline for Swift 4? >> >> On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution < >> [email protected]> wrote: >> >>> First, you should fix the indent in the code samples. Second, remove any >>> access modifier from inside a protocol. Third, we don’t support default >>> implementations directly inside protocols yet, so that’s a not valid >>> example. >>> >>> Now my personal concerns. As far as I can tell XIB files in an iOS >>> Project are meant for UIViewControllers in first place, but it’s a common >>> case that they are also used to create reusable UIViews. The downside of >>> that abusage is view hierarchy clustering. Most developer creating a view >>> of Self in Self, which smells to me like really bad code. >>> >>> MyCustomView // This view is useless >>> + MyCustomView >>> + CustomSubview1 >>> + CustomSubview1 // This is probably a dead IBOutlet >>> >>> In fact Xcode does not use the initializer from NSCoding to show a live >>> rendered view inside interface builder, instead it will call a UIViews >>> designated initializer init(frame:). That results that a lot of the >>> developer write similar code like in the following snippet: >>> >>> // This pattern results in a similar view cluster like mentioned above >>> >>> class MyCustomView : UIView { >>> override init(frame: CGRect) { >>> let view = loadSomehowFromNib() >>> self.addSubview(view) >>> } >>> } >>> >>> To solve this problem we’d need some functionality of factory >>> initializers. I believe as proposed the factory initializer won’t solve >>> that problem, because everything would be still restricted to a special >>> initializer annotated with factory. >>> >>> Personally I would want to write something like this instead. >>> >>> class MyCustomView : UIView { >>> >>> override init(frame: CGRect) { >>> >>> // Instantiating from a Nib file will call `init(coder:)` on >>> MyCustomView >>> self = loadSomehowFromNib() // assuming () -> MyCustomView >>> >>> // >>> self.frame = frame >>> } >>> } >>> >>> This should resolve the clustering issue by assigning the returned >>> instance from the function to self and create a correct view hierarchy. >>> >>> + MyCustomView >>> + CustomSubview1 >>> >>> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution ( >>> [email protected]) schrieb: >>> >>> Hi again everyone! >>> >>> Now that Swift 4 Stage 2 proposals are being considered, I thought it >>> might be time to revisit this proposal and see if it might align with the >>> goals set forth for Swift 4. >>> >>> As a quick tl;dr, this proposal describes a new "factory initializer" >>> that would allow you to return a value from an initializer. This would have >>> several benefits, as mentioned in the proposal itself as well as throughout >>> this mailing list. For convenience, here's a link to the proposal on >>> GitHub: https://github.com/rileytestut/swift-evolution/ >>> blob/master/proposals/NNNN-factory-initializers.md >>> >>> Would love to hear any more comments on this proposal, and if we feel >>> this is appropriate for considering for Swift 4 I'll happily re-open the >>> pull request! >>> >>> Riley Testut >>> >>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian <[email protected]> >>> wrote: >>> >>> i would appreciate this feature. >>> >>> For unexperienced developers, its often hard to recognize *when* factory >>> is a good fit to do the job, and how exactly approach the implementation. I >>> imagine having this feature built into the language may help to choose and >>> implement factory when its the right thing to do. >>> >>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution < >>> [email protected]> wrote: >>> >>> >>> Is there any chance of reviving this? It seems to me that since this >>> would require Swift initializers to be implemented internally in such a way >>> that they can return a value (as Objective-C init methods do), it may >>> affect ABI stability and thus may be germane to the current stage of Swift >>> 4 development. >>> >>> >>> Charles >>> >>> >>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution < >>> [email protected]> wrote: >>> >>> >>> Recently, I proposed the idea of adding the ability to implement the >>> "class cluster" pattern from Cocoa (Touch) in Swift. However, as we >>> discussed it and came up with different approaches, it evolved into a >>> functionality that I believe is far more beneficial to Swift, and >>> subsequently should be the focus of its own proposal. So here is the >>> improved (pre-)proposal: >>> >>> >>> # Factory Initializers >>> >>> >>> The "factory" pattern is common in many languages, including >>> Objective-C. Essentially, instead of initializing a type directly, a method >>> is called that returns an instance of the appropriate type determined by >>> the input parameters. Functionally this works well, but ultimately it >>> forces the client of the API to remember to call the factory method >>> instead, rather than the type's initializer. This might seem like a minor >>> gripe, but given that we want Swift to be as approachable as possible to >>> new developers, I think we can do better in this regard. >>> >>> >>> Rather than have a separate factory method, I propose we build the >>> factory pattern right into Swift, by way of specialized “factory >>> initializers”. The exact syntax was proposed by Philippe Hausler from the >>> previous thread, and I think it is an excellent solution: >>> >>> >>> class AbstractBase { >>> >>> public factory init(type: InformationToSwitchOn) { >>> >>> return ConcreteImplementation(type) >>> >>> } >>> >>> } >>> >>> >>> class ConcreteImplementation : AbstractBase { >>> >>> >>> } >>> >>> >>> Why exactly would this be useful in practice? In my own development, >>> I’ve come across a few places where this would especially be relevant: >>> >>> >>> ## Class Cluster/Abstract Classes >>> >>> This was the reasoning behind the original proposal, and I still think >>> it would be a very valid use case. The public superclass would declare all >>> the public methods, and could delegate off the specific implementations to >>> the private subclasses. Alternatively, this method could be used as an easy >>> way to handle backwards-compatibility: rather than litter the code with >>> branches depending on the OS version, simply return the OS-appropriate >>> subclass from the factory initializer. Very useful. >>> >>> >>> ## Protocol Initializers >>> >>> Proposed by Brent Royal-Gordon, we could use factory initializers with >>> protocol extensions to return the appropriate instance conforming to a >>> protocol for the given needs. Similar to the class cluster/abstract class >>> method, but can work with structs too. This would be closer to the factory >>> method pattern, since you don’t need to know exactly what type is returned, >>> just the protocol it conforms to. >>> >>> >>> ## Initializing Storyboard-backed View Controller >>> >>> This is more specific to Apple Frameworks, but having factory >>> initializers could definitely help here. Currently, view controllers >>> associated with a storyboard must be initialized from the client through a >>> factory method on the storyboard instance (storyboard. >>> instantiateViewControllerWithIdentifier()). This works when the entire >>> flow of the app is storyboard based, but when a single storyboard is used >>> to configure a one-off view controller, having to initialize through the >>> storyboard is essentially use of private implementation details; it >>> shouldn’t matter whether the VC was designed in code or storyboards, >>> ultimately a single initializer should “do the right thing” (just as it >>> does when using XIBs directly). A factory initializer for a View Controller >>> subclass could handle the loading of the storyboard and returning the >>> appropriate view controller. >>> >>> >>> Here are some comments from the previous thread that I believe are still >>> relevant: >>> >>> >>> >>> On Dec 9, 2015, at 1:06 PM, Philippe Hausler <[email protected]> wrote: >>> >>> >>> I can definitely attest that in implementing Foundation we could have >>> much more idiomatic swift and much more similar behavior to the way >>> Foundation on Darwin actually works if we had factory initializers. >>> >>> >>> >>> On Dec 7, 2015, at 5:24 PM, Brent Royal-Gordon <[email protected]> >>> wrote: >>> >>> >>> A `protocol init` in a protocol extension creates an initializer which >>> is *not* applied to types conforming to the protocol. Instead, it is >>> actually an initializer on the protocol itself. `self` is the protocol >>> metatype, not an instance of anything. The provided implementation should >>> `return` an instance conforming to (and implicitly casted to) the protocol. >>> Just like any other initializer, a `protocol init` can be failable or >>> throwing. >>> >>> >>> Unlike other initializers, Swift usually won’t be able to tell at >>> compile time which concrete type will be returned by a protocol init(), >>> reducing opportunities to statically bind methods and perform other >>> optimization tricks. Frankly, though, that’s just the cost of doing >>> business. If you want to select a type dynamically, you’re going to lose >>> the ability to aggressively optimize calls to the resulting instance. >>> >>> >>> >>> I’d love to hear everyone’s thoughts on this! >>> >>> >>> Best, >>> >>> Riley Testut >>> >>> _______________________________________________ >>> >>> 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 >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> >> -- >> *Pranshu Goyal* >> *iOS Developer* >> *tlkn* >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > -- *Pranshu Goyal* *iOS Developer* *tlkn*
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
