Skip to content

Conversation

@josevalim
Copy link
Member

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!

Stream,
String,
Time,
Tuple,
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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 Term in the tuple is called an element. The number of elements is said to be the size of the tuple.

@michalmuskala
Copy link
Member

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.

@josevalim josevalim added this to the v1.6.0 milestone Jan 7, 2018
@josevalim
Copy link
Member Author

You could easily view range as an optimised collection of sequential integers.

I like Collections if we can agree with the above.

@ianrumford
Copy link
Contributor

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.

@josevalim
Copy link
Member Author

josevalim commented Jan 8, 2018

But adding these groups are even more confusing for newcomers in my view

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.

@elixir-lang elixir-lang deleted a comment Jan 8, 2018
@elixir-lang elixir-lang deleted a comment Jan 8, 2018
@josevalim josevalim merged commit 4e01713 into master Jan 11, 2018
@josevalim
Copy link
Member Author

❤️ 💚 💙 💛 💜

@josevalim josevalim deleted the jv-collections-group branch January 11, 2018 09:07
josevalim added a commit that referenced this pull request Jan 11, 2018
@josevalim
Copy link
Member Author

josevalim commented Jan 18, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

5 participants