-
Notifications
You must be signed in to change notification settings - Fork 29
#3203. Add tests for private named parameters #3377
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
eernstg
left a comment
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.
LGTM, awaiting further input.
eernstg
left a comment
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.
LGTM, awaiting further input.
nshahan
left a comment
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.
One question for you but otherwise LGTM.
| Expect.equals("null", xRef1.valueAsString); | ||
| final xRef2 = | ||
| await service.evaluateInFrame(isolateId, 0, 'this._x') as InstanceRef; | ||
| Expect.equals("null", xRef2.valueAsString); |
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.
It is confusing to me that we expect _x and this._x to both be null at this time. Why?
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.
Based on the current behaviour of
class C {
String x;
C(this.x);
}x is null at this step. Therefore, I believe, that in this test _x also should be null.
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.
If the current location in code is the initializer list (we could add an initializer list, or we might have stopped at a breakpoint "in the initializer list" even though it's empty, which could be the way the VM sees it) then x would denote the parameter. In contrast, at any location with access to this, including the body of the constructor (if any), x would denote the instance variable, and so would this.x.
The same would be true with _x.
If the current position in code is the initializer list it might still be possible to access the instance variables of the enclosing object using terms like this.x or this._x. The language doesn't allow us to do that, but the debugger might.
So I've argued that we should at least know how it's supposed to work, and preferably look at the treatment of both the parameter and the instance variable in situations where it is the intention that both can be viewed and possibly modified.
eernstg
left a comment
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.
(Send an unsent comment.)
2025-11-05 sgrekhov22@gmail.com dart-lang/co19#3330. Add static extensions tests. Part 1. (dart-lang/co19#3381) 2025-11-05 sgrekhov22@gmail.com dart-lang/co19#3203. Add tests for private named parameters (dart-lang/co19#3377) 2025-11-05 sgrekhov22@gmail.com dart-lang/co19#3203. Add VM - CFE interaction tests for primary initializer scope (dart-lang/co19#3359) R=athom@google.com, eernst@google.com Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try,dart2js-minified-linux-d8-try Change-Id: Ibc9148c6d03bbc0b1f89ec5ad1e36e3171965779 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/460280 Auto-Submit: Sergey Grekhov <sgrekhov22@gmail.com> Reviewed-by: Erik Ernst <eernst@google.com> Commit-Queue: Alexander Thomas <athom@google.com> Commit-Queue: Erik Ernst <eernst@google.com> Reviewed-by: Alexander Thomas <athom@google.com>
No description provided.