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

[Colin Cornaby]

Yeah, thinking this one through… The use case below also mentioned the possibility of a setup function that had parameters to base it’s setup on. A lazy loading variable doesn’t necessarily cleanly replace that sort of usage without adding more variables to hold the parameters for lazy initialization… But I’m not sure if that’s realistic. Anything that’s part of an initWithCoder serialization /deserialization pattern is probably going to be a variable on the object anyway. Maybe someone else can come up with a better counterexample.

At least this list is a great way to touch on all the different corners of Swift. :)

> On Dec 15, 2015, at 6:14 PM, Marc Knaup <marc at knaup.koeln> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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/ce196ea7/attachment.html>