-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Introduce a group for collections #7185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| Stream, | ||
| String, | ||
| Time, | ||
| Tuple, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should Tuple also live in collections?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say Tuple is a composite type but not a collection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first paragraph of the Tuple documentation says: Tuples are ordered collections of elements. Should we update the documentation expressing is a composite type?
The Erlang documentation says:
A tuple is a compound data type with a fixed number of terms:
{Term1,...,TermN}Each term
Termin the tuple is called an element. The number of elements is said to be the size of the tuple.
|
I think this is a move in the right direction, I'm not particularly convinced by the name "Collections & Enumerables" - I think "Collections" or "Collection Types" would be enough. You could easily view range as an optimised collection of sequential integers. |
I like Collections if we can agree with the above. |
|
The above discussion just highlights my point :-) There is no "solution" and all groupings are essentially arbitrary. A while ago I opened #6571 regarding the removal of the distinction between "functions" from "macros" in Kernel.SpecialForms. Jose made the point that newcomers found that confusing. I accepted that. But adding these groups are even more confusing for newcomers in my view and I can't reconcile keeping it simple for newcomers v adding these groups which really only make sense to people who already know their way around the the language. Which goes to the heart of who is the target audience for the reference documentation? If its newcomers (and I think that's best) then the simpler the better. |
As I said in #7184, we need to validate this. Otherwise, we will only be guessing which one is better. Once the release is out and we get more people joining the community, we will be able to collect their feedback. |
|
❤️ 💚 💙 💛 💜 |
|
Good call, we should update it.
--
*José Valimwww.plataformatec.com.br
<http://www.plataformatec.com.br/>Founder and Director of R&D*
|
Currently the docs have a large group called "Data & Behaviour". The goal of this PR is to extract "Collections" (lists, sets, etc) and "Enumerables" (such as ranges) into their own group. Feedback is welcome!