Test GROUP! compatibility alias for PAREN! #98
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This gets rid of /WORD on the main TYPE-OF native, which was not really necessary because you could always write TO-WORD TYPE? but it was considered cleaner to say TYPE?/WORD. The TYPE? function is given a /WORD refinement for compatibility purposes. One good reason for losing the refinement is the ability to lax-compare a word against its type from 9754402 (strict comparisons will still not consider any datatype! equal to any word!). Unfortunately, until that setting cannot be turned off, any mezzanine or system code which has to run with legacy code must assume the feature is not available. Hence TO-WORD (or TO WORD!) is still necessary several places, but marked with OPTIONS_DATATYPE_WORD_STRICT to be cleaned up when that is deemed no longer necessary. Something emergent from this is that the datatype equality test and the TYPE?/WORD legacy point present an opportunity window for changing the names of types which needs to be focused on sooner rather than later. As long as TYPE?/WORD references exist in code that uses the old name of a type, it can give back the old type while new written clients go along happily with the new names. e835358 summarizes the issue.
|
Rebased and merged in e835358 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Renaming types in Rebol has technical barriers that are more like
renaming a dialect keyword than a function.
This gets the process started on a GROUP! rename by first testing
the compatibility tricks which would be used for PAREN! on it.
That means GROUP! is the compatible type, while PAREN! is the
"real" datatype. The fallout can be studied for what can be made to
work or not, and make it better before the switch is flipped to bias
it the other way where PAREN! is the alias and GROUP! is the
actual type.
This is spurred by realizing that the TYPE?/WORD call is a good
place to leave in compatibility code for returning PAREN!. But now
with the feature of being able to compare type names and words
loosely that people will be tempted to use the feature...dropping
the /WORD refinement. If that happens before any type renames,
then it makes it harder to keep compatibility.
So logistics of any type renames needs to get started sooner
rather than later. This will give some experience with it.