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

[Marc Knaup]

initWithCoder(_:) is exactly such an example you can solve using
initialization closures and/or lazy vars I mentioned earlier.

The only limitation would be that properties must be initialized
independently from each other.
If they really depend on each other then using a struct for them probably
makes sense since that can be initialized as a whole.

On Wed, Dec 16, 2015 at 3:00 AM, Colin Cornaby <colin.cornaby at mac.com>
wrote:

> 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>
>  wrote:
>
>> On Dec 15, 2015, at 7:06 PM, Marc Knaup <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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/2c5e4321/attachment.html>