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

Improving widgets for take/drop #6641

Merged
merged 18 commits into from
May 12, 2023
Merged

Conversation

radeusgd
Copy link
Member

@radeusgd radeusgd commented May 10, 2023

Pull Request Description

Related to #6410

Important Notes

  • Updated some Meta methods (needed for error handling):
    • Meta.Type now has name and qualified_name.
    • Meta.Constructor has declaring_type allowing to get the type that this constructor is associated with.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@radeusgd radeusgd added the CI: No changelog needed Do not require a changelog entry for this PR. label May 10, 2023
@radeusgd radeusgd self-assigned this May 10, 2023
@radeusgd radeusgd force-pushed the wip/radeusgd/take-drop-widgets branch from 945da8f to 139cc29 Compare May 11, 2023 20:28
@radeusgd
Copy link
Member Author

Widget shows what the default values will be:
image

If no value is provided and no default - a more friendly error is displayed:
image

@radeusgd
Copy link
Member Author

Updated after discussion:

image
image

@radeusgd
Copy link
Member Author

Got the widgets on Text working as well:
image
image
image
image
image

btw. the default visualization for empty text is just empty square box - that is a bit confusing - looks as if the visualization has failed.

Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a justification for the changes in Meta? I don't see it in PR description and the referenced issue seems too broad.

cons = case meta_typ of
Meta.Type.Value _ -> meta_typ.constructors
_ -> Test.fail "Should be a Meta.Type.Value: " + meta_typ.to_text

cons.length . should_equal 1
cons.at 0 . should_be_a Meta.Constructor
cons . map (x -> x.name) . sort . should_equal [ "Value" ]
cons.each ctor->
ctor.parent_type . should_equal meta_typ
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why it should be called parent_type? "Parent" is meant for other things: I can say: Any is parent type of Text and other types as well. Or Number is parent type of Integer. But constructor doesn't have a "parent type".

Java is using declaring class.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I can rename to declaring_type. Does that sound OK?

@radeusgd
Copy link
Member Author

radeusgd commented May 12, 2023

Is there a justification for the changes in Meta? I don't see it in PR description and the referenced issue seems too broad.

Fair point, I updated the PR description.

The justification is:

  • I needed parent_type (now declaring_type) to be able to easily check if a provided constructor is associated with one of expected types (when we add a more helpful error message) or not (where we just throw type error).
  • I needed short_name (now name), because Enso_Type.to_text is as we know (Type.to_text shall invoke instance method #6300) not reliable. Oh I guess I may have forgot it was fixed 😅

@radeusgd radeusgd force-pushed the wip/radeusgd/take-drop-widgets branch from 607a455 to bd90f76 Compare May 12, 2023 12:15
@radeusgd radeusgd requested a review from JaroslavTulach May 12, 2023 12:15
Copy link
Member

@jdunkerley jdunkerley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Couple of little things.

Copy link
Member

@jdunkerley jdunkerley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Couple of little things.

@radeusgd
Copy link
Member Author

Added Range:
image
image
image

I used the defaults from Range.new definition.

@radeusgd radeusgd added the CI: Ready to merge This PR is eligible for automatic merge label May 12, 2023
@radeusgd radeusgd force-pushed the wip/radeusgd/take-drop-widgets branch from aa7a849 to af10b38 Compare May 12, 2023 14:21
@mergify mergify bot merged commit f5071a1 into develop May 12, 2023
@mergify mergify bot deleted the wip/radeusgd/take-drop-widgets branch May 12, 2023 15:33
@JaroslavTulach
Copy link
Member

I needed parent_type (now declaring_type) to be able to easily check if a provided constructor is associated with one of expected types (when we add a more helpful error message) or not (where we just throw type error).

Is declaring_type the goal or is "more helpful error message" when "throw(ing) type error" the goal? If the latter, shouldn't it rather be addressed by #6682 than extending Meta capabilities?

Procrat added a commit that referenced this pull request May 15, 2023
…z-6260

* develop:
  Build nightlies every day. (#6681)
  Force `newDashboard` default on the CI-built packages. (#6680)
  Verify ascribed types of parameters really exist (#6584)
  SuggestionBuilder needs to send ascribedType of constructor parameters (#6655)
  Improvements to the Table visualization. (#6653)
  Removing flush (#6670)
  Improving widgets for take/drop (#6641)
@radeusgd
Copy link
Member Author

I needed parent_type (now declaring_type) to be able to easily check if a provided constructor is associated with one of expected types (when we add a more helpful error message) or not (where we just throw type error).

Is declaring_type the goal or is "more helpful error message" when "throw(ing) type error" the goal? If the latter, shouldn't it rather be addressed by #6682 than extending Meta capabilities?

Indeed, the latter. I guess that #6682 will be the general solution to this. Although this particular solution actually creates a more helpful message (partially using declaring_type) than a default configuration type check would. The thing is we detect that an 'unapplied constructor' of the correct type has been passed - and instead of issuing a type error we issue an 'Illegal_Argument' saying that some arguments are missing on the constructor.

Perhaps it can be an inspiration for the typechecker as well - it may indeed be very good for UX to detect situations when an unapplied constructor of the correct type is passed and instead of issuing a type error, issuing an error telling the user they are missing some arguments. Do you think we can do it in #6682? I assume it would "just" require adding a special case to the error reporting logic that checks if the unexpected element is a constructor of an expected type and reporting a slightly different error then.

Procrat added a commit that referenced this pull request May 16, 2023
* develop:
  Build nightlies every day. (#6681)
  Force `newDashboard` default on the CI-built packages. (#6680)
  Verify ascribed types of parameters really exist (#6584)
  SuggestionBuilder needs to send ascribedType of constructor parameters (#6655)
  Improvements to the Table visualization. (#6653)
  Removing flush (#6670)
  Improving widgets for take/drop (#6641)
  disable authentication and newDashboard by default (#6664)
  Add COOP+COEP+CORP headers (#6646)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants