-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Support C++ style friend semantics #22841
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
Comments
This comment was originally written by [email protected] Er, a mistake in the above. _rpc.getXForFoo() should be _rpc.getBazForFoo() |
This comment was originally written by [email protected] Sorry, another correction. FooModel createFooModel() { |
Added Area-Language, Triaged labels. |
What about just analyzer support, for example with an I have a large API where everything needs to be accessible internally, but for references passed out to the user the auto-completion of the IDE should only list what the user is supposed to use. The analyzer should hint/warn about access to internal members. Runtime semantics don't concern me. Wrapping everything with proxies that only provide a subset of the members before passing a reference is just too cumbersome.
Placing classes outside and inside of |
There are several other concurrent threads on friends or internal or visibility options. |
This issue was originally filed by [email protected]
Consider the following set of classes:
library foo.model;
class FooModel {
int _bar;
int _baz;
FooModel(this._bar);
int get bar => _bar;
int get baz => _baz;
set baz(int val) { _baz = val; }
}
library foo.service;
class FooService {
RpcMaker _rpc;
FooService(this._rpc);
FooModel createFooModel() {
var model = new FooModel(2);
return _rpc.getXForFoo().then((val) => model.baz = val);
}
}
library foo.user;
class FooUser {
FooUser(FooService service) {
var model = service.createFooModel();
print(model.bar);
doSomething().then((_) => print(model.baz));
}
Future doSomething() {
// Make some RPC or something.
}
}
The thing of note here is that I have some object I need to initialize asynchronously after an RPC is made. Since FooService is in a different library from FooModel, I have to expose the baz setter in order to allow FooService to set it. I also cannot make FooService return a Future<FooModel>, since I need to use the synchronously provided value of bar.
I think a good solution for this problem would be to specify that my FooService class is a friend of the FooModel class, thus allowing me to set the internals without having to resort to a Builder/View pattern.
Another major reasong adding C++ friend classes could be useful is in testing.
The text was updated successfully, but these errors were encountered: