Skip to content
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

Let EnsoMultiValue.to_text delegate to first type to_text #11827

Open
JaroslavTulach opened this issue Dec 11, 2024 · 2 comments · May be fixed by #12192
Open

Let EnsoMultiValue.to_text delegate to first type to_text #11827

JaroslavTulach opened this issue Dec 11, 2024 · 2 comments · May be fixed by #12192
Assignees

Comments

@JaroslavTulach
Copy link
Member

JaroslavTulach commented Dec 11, 2024

Based on to_text discussion, but overall question is: what should EnsoMultiValue do with Any methods? If we delegate to_text to the first type, then we should probably delegate all of them. @radeusgd originally wrote:

IMO to_text of first type is best. It does hide the 'other values' and that is not ideal, but given the kind of use cases we want to use multi-values for (e.g. the Column & Integer_Column), I think that delegating to the first type is the best we can do to keep this sensible.

In that regard, perhaps to_text shouldn't be any different than e.g. to_js_object or to_defautl_visualization_data that we use to visualize the values. These will also delegate to the first value.

Originally posted by @radeusgd in #11600 (comment)

@JaroslavTulach
Copy link
Member Author

JaroslavTulach commented Dec 20, 2024

As a side note: Any.to should probably use EnsoMultiValue as self: #11897 (comment)

Update on Jan 24, 2025: Another example where EnsoMultiValue should be send as self is here https://github.com/enso-org/enso/pull/12120/files#r1928099736 - again needed for dispatch of Any instance methods.

@radeusgd
Copy link
Member

radeusgd commented Jan 24, 2025

As a side note: Any.to should probably use EnsoMultiValue as self: #11897 (comment)

Update on Jan 24, 2025: Another example where EnsoMultiValue should be send as self is here https://github.com/enso-org/enso/pull/12120/files#r1928099736 - again needed for dispatch of Any instance methods.

Indeed it would be good if methods like catch or throw_on_warning did not lose the intersection types. It is not intuitive that they would be lost (I understand why it happens but writing the code it is not an intuitive behaviour) - it requires the user to think hard whether their code may be getting an intersection type and do workarounds to avoid losing it. That is definitely not desirable - I think the intersection types should be as transparent as possible.

GitHub
Pull Request Description

First experiments with intersection types as refinements to our Table/Column
Closes #12095

Important Notes

Checklist
Please ensure that the following checklist has been ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🔧 Implementation
Development

Successfully merging a pull request may close this issue.

2 participants