Skip to content
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

Any list clarity #2252

Merged
merged 4 commits into from Aug 10, 2018
Merged

Any list clarity #2252

merged 4 commits into from Aug 10, 2018

Conversation

MorayJ
Copy link
Contributor

@MorayJ MorayJ commented Aug 10, 2018

The problem

The "1-item list" in Any docs is inaccurate #2176

Solution provided

I have standardised the language based on other language in the document, though will need checking by someone with a greater understanding of what's actually being said.

Looking at the Cool type document, I have changed all descriptions which say 'coerce' to 'coerces' as there were both in the document.

I have added 'the invocant' in many places and hope this is correct to fit in with the language I was using in this update. Again, this was something used sporadically and I had to choose what to follow. It is now more consistent.

I have referred to C<List> meaning a class, rather than just 'a list'. Again, this seems more consistent to me with the rest of the document.

Moray added 2 commits August 10, 2018 17:38
If method .class is not the default .class, may not return a one element list.

Documentation now refers to creating a List with the invocant's .class method.

Makes the language relatively consistent over a number of method descriptions.
@MorayJ MorayJ requested a review from zoffixznet August 10, 2018 16:57
@zoffixznet
Copy link
Contributor

Looks good except for the:

I have referred to C<List> meaning a class, rather than just 'a list'.

There's a deliberate difference there. Note there are both .List and .list methods. Only .List specifically coerces to a List type; .list is allowed to coerce to any Positional type:

[].List.^name.say; # List
[].list.^name.say  # Array

(the same thing exists for .Hash vs .hash; the latter is allowed to return any Associative)

@MorayJ
Copy link
Contributor Author

MorayJ commented Aug 10, 2018

Ok, will have another go...see it's failed a test as well.

Moray added 2 commits August 10, 2018 19:21
@MorayJ
Copy link
Contributor Author

MorayJ commented Aug 10, 2018

Having doubts about methods pairs, anti-pairs and kv. Based the re-wording on method pairs and not sure that it's correct in List v list..? Bit out of my depth there. Should I revert that part?

But otherwise, I think this is ok as far as fixing the related bug?

@zoffixznet
Copy link
Contributor

Having doubts about methods

The only thing I see is the use of word undefined. Should be changed to something like …if the invocant is a type object. The non-definite objects (i.e. type objects rather than instances) are slightly different from "undefined" objects. An object can override the .defined value (and some things like Failures do) and can be false even for instances:

say Failure.new.DEFINITE; # True
say Failure.new.defined;      # False

@zoffixznet zoffixznet merged commit 85feebe into Raku:master Aug 10, 2018
@zoffixznet
Copy link
Contributor

👍 Thanks!

(gonna fix up the defined thing myself; need to do some other edits in the same area and don't want to introduce merge conflicts).

@MorayJ MorayJ deleted the any-list-clarity branch August 11, 2018 09:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants