Mathics 5.0 upgrade #4
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This now about does it. There are a couple of get_string_value's still in there in those places where we haven't ensured that we are working with String.
There was a time long long ago when you will see one of the maintainers proding contributors not to use
.valueand use the (more awkward)get_xxx_value().That was then and this is now. The reason we use
.valueis for a couple of reasons. It is not just an artistic kind of thing, but this is actually the convention that many interpreters use. And part of it is that if you have some Object (or boxed, or wrapped) form of a primitive data type and you want the underlying primitive data, it isn't desired to make those look different: soi.valueands.valueinstead ofi.get_int_value()ands.get_string_value(). If somehow you are upset about the accessor not reflecting the type (which in other interpreters is considered a good thing), then the way you get that back is via type annotations, not method naming.Perhaps in the days before type annotations a better argument could be made. But again, that was then, and this is now.