-
Notifications
You must be signed in to change notification settings - Fork 334
Defining to_text & co. as extension methods
#14050
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
Conversation
to_text & co. as extension methods
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to need to add from project.Data.Text.Extensions import all to a lot of files in Standard.Base.
Think about 57 files need it added,
|
Take This would have worked previously but will now error as this code does not import Text extensions. |
|
Ones I suspect (but maybe false positives):
|
|
Enso, at it roots, is a **conversion oriented language**. Enso supports flexible definitions of conversions of values of a type to another. To stress the importance of conversions in usage of the Enso language, there is `Any.to target_type` method available on any value in the Enso system that allows to _morph and view any object as a different type_ easily when such a conversion is available. In addition to that Enso is **structured equality oriented language**. There is `Any.==` operator that allows any two values to be compared for equality. The comparison is based on structure - e.g. two instances of the same atom with equal fields are the same. Enso provides such a _structured equality_ implementation to every user defined type automatically, yet it also offers more complex equality handling when needed (via `Comparable` type). Enso is **conversion and** (structured) **equality oriented language**. That fact is stressed by the shape of its root type `Any`. It exposes just `.to`, `==` and `!=` operations. # Important Notes - To fulfill the promise of Enso being **conversion and equality oriented language** - this PR proposes to turn `Nothing` related methods into _extension methods_ - e.g. to move them out of `Any` type into `Nothing` type - the change is supposed to be compatible for everyone using `from Standard.Base import all` - this PR is the final step finishing the work previously started by - #14004 - #14003 - #13978 - #14017 - #14050 - in the tradition of those PRs let's argue: - it is better to be somebody, or at least anybody - nobody wants to feel like `Nothing` - hence we don't want Enso to feel like "nothing oriented language" - as such `Nothing` related methods should be provided only as extension methods! - on a more technical note: `obj.is_nothing.not` can actually be written as `obj!=Nothing`, not sure why we prefer the former (and longer) variant? Maybe some FP bias!?

Pull Request Description
>,>=,<,<=to types where such operators make sense #14017Any#13978|>operator to Function #14004from Standard.Base import allImportant Notes
to_textinAnyprettyandto_display_textclearly seem weirdTObjecthad no methods at all!Any.tois perfectly fine in the root typeto_display_text,prettyout ofAnyis a completely legitimate goalChecklist
Please ensure that the following checklist has been satisfied before submitting the PR: