On 29.04.2016 2:21, Howard Lovatt via swift-evolution wrote:
I like the `defer init` idea but suggest you have to explicitly call it at
the end of all the other non-convenience `init`s. The advantage of an
explicit call are two fold:
1. It is obvious what is happening
2. You can pass arguments
Like this idea very much. IMO it is important to see that "defer init" will
be called at the end when we are looking at the code of init. Otherwise we
need to don't forget that "defer init" could be also defined and are called
at the end of this init.
P.S. Sorry for duplicate.
On Friday, 29 April 2016, Basem Emara via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
I see what you’re saying and the forced optionals is pretty inconvenient.
As far as syntax, how about more of a “deferred” init that gets
triggered regardless like this:
defer init() {
// Always gets called no matter what designated init triggers
}
> On Apr 27, 2016, at 5:52 PM, Shannon Potter via swift-evolution
<[email protected]> wrote:
>
> Consider a relatively-common init pattern:
>
> class SomeViewController: UIViewController {
>
> // MARK: Properties
>
> private var videoPlayer: AVPlayer
> private var videoPlayerLayer: AVPlayerLayer
>
> // MARK: - Object Lifecycle
>
> override init(nibName: String?, bundle nibBundle: NSBundle?) {
> super.init(nibName: nibName, bundle: nibBundle)
>
> commonInitialization()
> }
>
> required init?(coder decoder: NSCoder) {
> super.init(coder: decoder)
>
> commonInitialization()
> }
>
> private func commonInitialization() {
> videoPlayer = AVPlayer(...)
> videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
> }
>
> }
>
> This does not work. Both properties are non-optional, and the
compiler complains that they are not initialized in either init method.
It seems rather common to want a single point of contact regarding
object initialization, regardless of the path taken to initialize that
object. Ideally, objects could all be funneled to one designated
initializer, but this isn’t always the case.
>
> What are people’s thoughts about either a specialized function that
is always called at the very end of each object’s lifecycle OR some
sort of attribute for a function that hints that the compiler should
follow it if called in an init function to check for property
initialization?
>
> func commonInit() {
>
> }
>
> or
>
> @extend_init private func commonInitialization() {
>
> }
> _______________________________________________
> 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
--
-- Howard.
_______________________________________________
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
