Eliminate @proxy from language spec for 2.0

[vsmenon]

Making sure this is tracked. I think we agreed to eliminate.

@floitschG

[bergwerf]

Aha, I just encountered analyzer issues with this in the dev channel. This means JsonObject no longer works without the analyzer complaining, and its use should probably no longer be advertised on the Dart website. Would it be possible to opt-in for using proxy? I used noSuchMethod to implement HTML generators that provide a very nice alternative to HTML templating, e.g. you can write html(lang: 'en', c: [...]). To remain compatible with future Dart I might now have to change some of the routines here. I also use JsonObject to generate these pages because they offer a nice way to access JSON data from a rest service. For me it would be a serious disadvantage to uglify my code again. Thoughts on this? (for now I can just use dynamic types wherever I use JsonObject to silence the analyzer, but can I keep using that approach in future versions of Dart?, Dart 2.0 will still have dynamic types right?)

[eernstg]

proxy has been removed from the language specification as of 06f2a2e.

@bergwerf: Please resubmit your concern (could just be a copy-paste of the text that you wrote above) in a different issue: This issue is about the update to the language specification, and that step has been taken.

There are no plans to support anything like @proxy in Dart 2, but it's worth noting that it does very little even in Dart 1: It allows for arbitrary member accesses when the static type of the receiver has the annotation @proxy, but it does not allow (this is Dart 1 so we need to say "in checked mode") for such an instance o to be the value of a variable/parameter whose type annotation is not a supertype of the dynamic type of o. For example:

abstract class A { int foo(); }

@proxy
class B {
  noSuchMethod(i) => 42;
}

main() {
  // Let's pretend that a `B` is an `A`:
  int i = new B().foo();
  // Works! `new B().foo()` type checks because of `@proxy`, and at runtime
  // `noSuchMethod` does something which is OK for emulating `A.foo`.

  A a = new B();
  // Fails (in checked mode)! A `B` really isn't an `A`.
}

So it's a very shallow kind of masquerading: You can treat something of type B as if it were of type A (or any other type, everything is allowed), but you can't pass a B through any typed code (by assigning it to a variable or passing it as an actual parameter, or anything else where it is actually required that we have an A.

So what you can do right now is to make sure that your JsonObject instances get type dynamic rather than JsonObject, and then you can still call arbitrary methods on it.

In any case, I'm sure there is someone who knows much more about the concrete setting where you are using those JsonObjects etc, so I won't attempt to give anything like a complete answer here, so I think the right thing would be to re-post your request in a different issue, possible a brand new one if nothing of the sort has been discussed already.

[bergwerf]

Thank you, I might do so. I stopped actively using JsonObject in favor of a custom generated reflection system that can use dart classes to encode/decode JSON objects.

…

On Thu, Jan 25, 2018, 23:18 Erik Ernst ***@***.***> wrote: Closed #30220 <#30220>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#30220 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEQJ1Z74jYmu0QD7uZqF0eOckQiTvvL9ks5tOP22gaJpZM4OewRI> .