Moving Warning related methods out of Any
#13978
Merged
Conversation
This file contains hidden or 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
JaroslavTulach
requested review from
AdRiley,
GregoryTravis and
jdunkerley
as code owners
JaroslavTulach
added
the
CI: No changelog needed
GregoryTravis
approved these changes
Sep 9, 2025
github-actions
bot
added
the
-libs-API-change-Base
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-09-09): Progress: .
|
…gExtensionMethods
|
If the approach of this PR is found sane, then we could continue with Nothing.diff.gz. Again compatible when |
jdunkerley
approved these changes
Sep 11, 2025
Thanks for the approval James. Let's integrate the warnings part. What's is your opinion about the |
I think I disagree on |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-09-11): Progress: .
|
Ok. That's valid view. |
This was referenced Sep 13, 2025
5 tasks
mergify bot
pushed a commit
that referenced
this pull request
Oct 9, 2025
- in the tradition of #14017 - and previous #13978 - and #14003 - and #14004 - let's make Enso less _"to text oriented"_ language - there should be **no API change** for those who `from Standard.Base import all` # Important Notes - coming from Java with its [Object.toString](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()) - one might be fine with `to_text` in `Any` - however `pretty` and `to_display_text` clearly seem weird - moreover my object oriented roots are in [Turbo Pascal 5.5](https://en.wikipedia.org/wiki/Turbo_Pascal#Object-oriented_programming) - the root object there - the `TObject` had no methods at all! - while _clean_ (e.g. Turbo Pascal was no "[something oriented language](https://wiki.apidesign.org/wiki/RootClass)", but trully _just an object oriented language_) - I don't call for that in case of Enso - ultimatelly I'd like Enso to be _"conversion oriented language"_ - e.g. `Any.to` is perfectly fine in the [root type](https://wiki.apidesign.org/wiki/RootClass) - with all the _extension method_ capabilities Enso has, I believe moving `to_display_text`, `pretty` out of `Any` is a completely legitimate goal
4 tasks
mergify bot
pushed a commit
that referenced
this pull request
Oct 12, 2025
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!?
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.
Pull Request Description
AnyandWarningtypesWarningmodule is importedfrom Standard.Base import allAny- e.g. extend root classis_magicalis available on every object to everyone importingMy_MagicMy_Magicaren't "disturbed" by such extensionsChecklist
Please ensure that the following checklist has been satisfied before submitting the PR:
style guides.