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

[Marc Knaup]

Well lazy vars actually can refer to each other during their initialization.
Just make sure you don't create any cycles or else you'll end up in an
endless recursion.

On Wed, Dec 16, 2015 at 3:06 AM, Marc Knaup <marc at knaup.koeln> wrote:

> 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/41de56bf/attachment-0001.html>