[swift-evolution] Proposal: 'selfless' keyword for refactoring duplicate code from initialisers

[Colin Cornaby]

In UIKIt a view can have two primary methods of initialization: initWithCoder and initWithFrame. initWithCoder is special in that it will not call up to initWithFrame, while any other initializer will use initWthFrame as it’s base initializer.

A common issue is that you might want to set defaults based on runtime information, so you define a common “setup” function that each one of the initializers calls. Again, I haven’t run into this case yet in Swift, but my understanding is that this would not work because the initializers would not be able to call a function on themselves until initialization was complete.

There is one possible way out. NIB outlets are declared implicitly unwrapped to work around this exact problem. A NIB can’t be loaded until after the object’s initialization is complete, and therefore the outlet properties of the object can’t be populated at init time. Any properties that need to have common setup between the two initializers could be declared as implicitly unwrapped. You’d lose some safety, but any issues could probably be quickly caught. This would work around the problem of needing to populate all the properties of the object before calling to the super’s init.

> On Dec 15, 2015, at 5:51 PM, Marc Knaup via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Although I understand your concerns (Charles and Ross) I think an extensive example is still necessary to properly discuss this proposal. We'd have to figure out what exactly causes the limitation, if there are alternatives and if there is no alternative which would render the change unnecessary.
> So far this is a very theoretical discussion.
> 
> 
> On Wed, Dec 16, 2015 at 2:48 AM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> On Dec 15, 2015, at 7:06 PM, Marc Knaup <marc at knaup.koeln <mailto:marc at knaup.koeln>> wrote:
>> 
>> In its current state with the initial example -1 from me for the proposal.
>> 
>> The example could easily be written like this:
>> 
>> class FooView: UIView {
>> 
>>     var property = 4
>> 
>>     init() {
>>         super.init()
>>     }
>> 
>>     init(frame: CGRect) {
>>         super.init(frame)
>>     }
>> }
>> 
>> 
>> In cases where the initially value is computed in a complex way a closure can be used:
>> 
>> class FooView: UIView {
>> 
>>     var property: Int = {
>>         // some complicated computation
>>         return value
>>     }()
>> 
>>     init() {
>>         super.init()
>>     }
>> 
>>     init(frame: CGRect) {
>>         super.init(frame)
>>     }
>> }
> 
> That works for simplistic cases such as this. However, if you have a large number of properties that all need to be set, and if their values are all interconnected in some way, dependent on some of the initializer’s parameters, or dependent on some value computed at runtime, this pattern cannot accomplish the task cleanly.
> 
> Charles
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/c716bbee/attachment.html>