docs(type): Provides an initial documentation document for the Type component

[veewee]

The README is based on the structure in php-standard-library/php-standard-library.github.io so that it can be displayed on the website. We concluded to add documentation in this repo, so I am providing it here already.

Currently it's an initial draft aiming on explaining what the component can be used for.
It now covers:

• Introduction
• Converted type
• Shape type

I am focussing on providing very detailed types and ideas on how to use them so that we maybe don't need to explain every single type in this package. (like int, float, ...)

[azjezz]

great start! could you remove this from docs/documentor.php and add it in the readme template like the other ones: https://github.com/azjezz/psl/blob/next/docs/templates/README.template.md#components ? thanks!

[coveralls]

Pull Request Test Coverage Report for Build 8716607211

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 98.781%

---

Totals
Change from base Build 8709891691:	0.0%
Covered Lines:	4377
Relevant Lines:	4431

---

💛 - Coveralls

[azjezz]

The README is based on the structure in php-standard-library/php-standard-library.github.io so that it can be displayed on the website.

Not sure if we want to keep the same format, as people would most likely read this on GitHub and locally, so maybe we can come up with a better format/style for documentation?

[veewee]

Not sure if we want to keep the same format, as people would most likely read this on GitHub and locally, so maybe we can come up with a better format/style for documentation?

I can base it on the format in https://github.com/azjezz/psl/blob/next/src/Psl/Async/README.md ?

[azjezz]

maybe? i don't know really. up to you :D

[veewee]

maybe? i don't know really. up to you :D

@azjezz

What do you think about current structure?
It's how I do it on my projects and it has some advantages:

• No usage of lists, making it easier to maintain
• Function names (and classes, ...) are level 4 headers that make it possible to link directly to that section of the page.
• These titles can be used as anchors to the code so that you can easily look at it yourself
• Separation is done with a --- gives you a clear indication where docs for that function stop.
• It's pretty standard, making it relatively easy to style in the docs website;

I'm also trying to give it a consistent structure:

• title
• type information (somewhat using @ as a replacement for dockblocks to make it shorter)
• What does assert / coerce act like
• Optional example (if its worth adding)

I tried visualizing this in the documentation website, but can't seem to find a way to visualize it locally. What are you using to display it before pushing it to github?

[azjezz]

This looks good overall.

I am still not sure about the format, but, we can keep it as is for now, and if we later decide on a different format, we can change it ( along with the other documentation files ).

[veewee]

I am still not sure about the format,...

Let me know if there is something specific you don't like, I can always change the format..