Make BaseNode init accessible outside the Down module

[daikini]

This pull request adds the public designator to the BaseNode.init initializer so that it can be called outside the Down module.

Fixes #196

[codecov]

Codecov Report

Merging #197 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #197   +/-   ##
=======================================
  Coverage   32.59%   32.59%           
=======================================
  Files          74       74           
  Lines        2362     2362           
=======================================
  Hits          770      770           
  Misses       1592     1592

Impacted Files	Coverage Δ
Source/AST/Nodes/BaseNode.swift	92.3% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cd1a3f6...d4f6b45. Read the comment docs.

[johnxnguyen]

Hi @daikini , thanks for the pull request. Could you elaborate on what problem this change solves?

[daikini]

Hi @johnxnguyen, I'm writing a new DownRenderable compatible renderer that uses theDocument class to traverse the AST tree with my custom Visitor. It is not currently possible to instantiate a Document outside of the Down framework because by default Swift treats the init method private outside the Down framework even though the Document class is itself public. The init method that Document uses is in its parent class the BaseNode class.

This PR fixes this issue by making the BaseNode.init method explicitly public so that it (and its subclasses) can be instantiated outside of Down.

Without this PR it is not possible to build new renderers for Down outside Down itself.

[iwasrobbed]

@daikini That's fair; as API design goes, it's always good to be careful about opening internal APIs up for use, but at the same time we should encourage custom renderers so the community can build their own use-case-specific tooling

Thanks for the extra detail 👍

[iwasrobbed]

As long as @johnxnguyen approves (versus an alternative approach), this seems reasonable to me

[johnxnguyen]

Glad to hear you’re making a custom renderer! I’m a bit hesitant to open the access of the initializer, because the node classes were never intended to be invoked outside of the framework. The reason being is because the CMarkNode is just a pointer to a C struct, and initializing a particular node class with the wrong pointer could lead to unexpected behavior.

To create the correct node class from a given CMarkNode instance, there is a handy extension method on CMarkNode called wrap() see here which will instantiate and return the node class (albeit type erased to the Node protocol type).

You could for instance do something like:

let down = Down(markdownString: “...”)
let document = try? down.toAST().wrap() as? Document
...

If this approach is too inconvenient, I would suggest to create a helper method or add a renderer that returns the Document node (just like the AST renderer returns the CMarkNode), instead of opening access for every BaseNode subclass.

[daikini]

@johnxnguyen, didn't know about the wrap() method. That works great. Thank you!