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
uniprop-* are not documented #1045
Comments
|
Please, can you clarify this issue? What is wrong with this - http://storage3.static.itmages.com/i/16/1211/h_1481449847_3051205_6b92fa7717.png ? |
|
It says that there is a “method unival” in Int, but there is no such method in Int. The method form is actually in cool which calls the sub form… uh, it's complicated! See this pull request (because after it this is going to change): rakudo/rakudo#945 |
|
So the task is to understand current situation and move sub/method descriptions from OldType to NewType(with optional examples update)? |
|
Yes, but we probably want to wait just a little bit for this PR to go through. |
|
PR has gone through. unival, unival, uniprop, uniprop-int, uniprop-bool, uniprop-st, uniprops, unimatch, uniname, unanames are all now in Cool |
|
List of work:
|
|
The three "dash" properties, do we need to describe them? That would leave only unival, which is already described in Int and Str |
|
We do need to document them, but either I don't understand their functionality or these subs are simply broken. See 39241d1. Another thing is that there's a table on Cool that says which sub coerces to what, and I think that for some of the subs mentioned here the table is incorrect (for uniprop at least). |
|
The three "uniprop-str", "uniprop-int" and "uniprop-bool" are not specced and essentially call the nqp ops directly. I.e. if you request the incorrect type then it will give you bogus information. For example, requesting the int value of something stored as an enum in moarvm will return the enum number and not the expected result. Though maybe MoarVM should not return bogus information, it's also rakudo's job not to ask for the correct type (we have logic in rakudo so the properties resolve correctly to the proper type). The only things .uniprop-int may be useful for is Canonical_Combining_Class which has strings as well as numbers specified. BTW .uniprop-int for CCC gives the enum's value not the assigned integer number. Though the numbers are correct relative to each other (the CCC numbers are most important relative to each other when doing rearrangement of codepoints inside a grapheme, to order the combining marks in the proper order to form NFG). |
https://docs.perl6.org/type/Int#routine_unival
https://github.com/rakudo/rakudo/blob/5476d60d09ec31690161eac1d9a876b2886e5ee0/src/core/Str.pm#L2993
The text was updated successfully, but these errors were encountered: