Add empty ASViewController initializer to facilitate subclassing

[christianselig]

Per Slack discussion with @nguyenhuy.

If you want to use ASViewController throughout your app as a generalized UIViewController stand in (as the docs mention) it's tricky (at least in Swift) when you want to take a non-node based normal UIViewController and make it inherit from ASViewController (again to perhaps have a consistent root subclass) because there's only one designated initializer in ASViewController, init(node:) which does not accept nil values despite the docs indicating that should be okay.

Currently the only course of action is to pass in a dummy node (e.g.: ASViewController(node: ASDisplayNode())). Other courses of action include unmarking init(node:) as the designated initializer or letting it accept nil values, but neither of those are optimal, per @nguyhuy:

ah, you only hit this limitation while subclassing. When people initialize it directly, we want to steer them to do the right thing by making the node param nonnull.

A proposed solution would be to introduce a second designated "empty" initializer that would just use the underlying UIViewController, make node nil, and facilitate subclassing, which is what I did in this PR.

Other context:

• [ASViewController] Support optional node facebookarchive/AsyncDisplayKit#3021
• Add NS_DESIGNATED_INITIALIZER to ASViewController initWithNode: #1054

[nguyenhuy]

@christianselig Thanks for putting together this PR and summing up the issue nicely.

To ensure the stand in capability that the doc mentions (and I personally believe it's a good thing), I can see 2 solutions:

• Mark -init as a designated initializer, essentially what this PR does.
• Remove NS_DESIGNATED_INITIALIZER flag of -initWithNode:, essentially revert #1054.

The second approach allows ASViewController to be a true stand in for subclassing while the first one is more surgical.

Either way, the new implementation of -init is needed because currently people can call it and the resulting instance wouldn't be initialized correctly.

Approving this PR but I'm interested in opinions from others as well.

[jparise]

Approving this PR but I'm interested in opinions from others as well.

It seems reasonable (to me) for both symbols to be annotated with NS_DESIGNATED_INITIALIZER because they both can be trusted to have correct subclass-friendly implementations, as you note:

Either way, the new implementation of -init is needed because currently people can call it and the resulting instance wouldn't be initialized correctly.

[rqueue]

Looks like an override keyword is missing
https://github.com/TextureGroup/Texture/pull/1740/checks?check_run_id=361456006#step:3:1553

[jparise]

@christianselig would you mind fixing up this Swift test?

/Users/runner/runners/2.163.1/work/Texture/Texture/examples/Swift/Sample/ViewController.swift:32:3: overriding declaration requires an 'override' keyword

Then we should be good to merge this. Thanks!

[christianselig]

@jparise I've seemingly since nuked the repo that this PR came from, but I recreated it, is there a way to link it to this specific PR or should I close this and create a new one?

[jparise]

@jparise I've seemingly since nuked the repo that this PR came from, but I recreated it, is there a way to link it to this specific PR or should I close this and create a new one?

If you have hub available, you can just do hub pr checkout 1740 to (re)checkout this branch.

Alternatively, something like this with vanilla git:

curl -L https://github.com/TextureGroup/Texture/pull/1740.patch | git am -3

[christianselig]

@jparise Not 100% sure I understand. I have the changes applied, but how do I then apply it against this PR specifically? Am I able to git push to a PR?

[jparise]

@jparise Not 100% sure I understand. I have the changes applied, but how do I then apply it against this PR specifically? Am I able to git push to a PR?

Ah, sorry, I misunderstood. I think it's probably easier to create a new PR. I don't know the git(hub) magic for this case.

[christianselig]

@jparise Done, see #1754 😛

[jparise]

Closing in favor of #1754.