Change specification of @proxy to be compatible with implemementation.

Change specification of @proxy to be compatible with implemementation.

R=brianwilkerson@google.com, kasperl@google.com

Committed: https://code.google.com/p/dart/source/detail?r=31433

[gbracha, 2013-11-27 23:44:19]

Also lobotomized stack trace requirements.

[Brian Wilkerson, 2013-11-28 00:31:36]

LGTM

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.te...
docs/language/dartLangSpec.tex:4600: % Sadly, the info below cannot be computed
efficiently. It would need to be computed at the throw point, since at latte
points it might be destroyed. Native code in calling frames executes relative to
the stack pointer, which therefore needs to be reset as each frame is unwound. 
This means that the
"latte" --> "later"

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.te...
docs/language/dartLangSpec.tex:5084: It is a compile-time error if a name $N$ is
re-exported by a library $L$ and $N$ is  introduced into the export namespace of
$L$ by more than one export, unless all  exports refer to same declaration for
the name $N$.  It is a static warning to export two different libraries with the
same name.
Don't know whether you care, but there's an extra space here.

[kasperl, 2013-11-28 08:11:26]

LGTM. CC'ing Lasse to entice him to update the documentation for proxy in
dart:core.

[Lasse Reichstein Nielsen, 2013-11-28 09:50:10]

Duely noted.

[Lasse Reichstein Nielsen, 2013-11-28 10:03:48]

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.te...
docs/language/dartLangSpec.tex:3181: Let $T$ be the  static type of $o$. It is a
static type warning if $T$ does not have an accessible  (\ref{privacy}) instance
member named $m$ unless $T$ or a superinterface of $T$ is annotated with the
annotation \code{@proxy} defined in \code{dart:core}.   If $T.m$ exists, it  is
a static type warning if the type $F$ of $T.m$ may not be assigned to a function
type. If $T.m$ does not exist, or if $F$ is not a function type, the static type
of $i$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return
type of  $F$.
That means that you can get a warning if you have one member of a name, but
implement other signatures for that name via noSuchMethod.
Example:

  class Foo {
     int get bar(String x);
  }

  @proxy class Bar extends Foo {
     noSuchMethod(i) {
       if (i.memberName == #bar) {
          return this.bar(i.positionalArguments.join(","));
       }
       super.noSuchMethod(i);
     }
  }

This will still give a warning for:
  new Bar().bar("this","is","an","example")
even though the implementation works, and it's marked as @proxy.


In other words, I don't think we should give any warning if the class is a
@proxy, even if it has a member with a given name and it's getting used in a way
that is incompatible with that implementation.
The noSuchMethod can handle that too.

So, I'd prefer something like:

If a superinterface of $T$ is annotated with the annotation \code{@proxy}, there
are no warnings. Othwerwise it is a static type warning if $T$ does not have an
accessible  (\ref{privacy}) instance member named $m$. If $T.M$ exists, it ....

[Lasse Reichstein Nielsen, 2013-11-28 10:18:11]

Proxy documentation updated:   https://codereview.chromium.org/94553003

It is a serious problem that @proxy has no effect at runtime.
It means that any use of it will likely fail in checked mode.

To have actually working proxies, we would need a deeper language integration,
e.g., "implements Dynamic" or something closer to Java's dyamic proxies, e.g.,
  class MirrorSystem { 
     ...
     dynamicProxy(List<Type> types, action(InvocationMirror m));
  }

[Lasse Reichstein Nielsen, 2014-01-02 10:26:15]

On 2013/11/28 10:03:48, Lasse Reichstein Nielsen wrote:

> If a superinterface of $T$ is annotated with the annotation \code{@proxy},
there

Actually, that is causing confusion already.
It should perhaps say:
 If a superinterface of $T$ is annotated with the constant value \code{proxy}
from the core library, there 

The value is important, not the name. It must work if you write:

  const foo = proxy;
  @foo class X {}

and not it you write:

  const proxy = 42;
  @proxy class X {}

[gbracha, 2014-01-02 19:57:56]

On 2014/01/02 10:26:15, Lasse Reichstein Nielsen wrote:
> On 2013/11/28 10:03:48, Lasse Reichstein Nielsen wrote:
> 
> > If a superinterface of $T$ is annotated with the annotation \code{@proxy},
> there
> 
> Actually, that is causing confusion already.
> It should perhaps say:
>  If a superinterface of $T$ is annotated with the constant value \code{proxy}
> from the core library, there 
> 
> The value is important, not the name. It must work if you write:
> 
>   const foo = proxy;
>   @foo class X {}
> 
> and not it you write:
> 
>   const proxy = 42;
>   @proxy class X {}

It actually says that the annotation is the one define in dart:core, so the
latter misinterpretation is not a concern. The former should be clarified.

[gbracha, 2014-01-02 22:14:53]

Committed patchset #3 manually as r31433 (presubmit successful).

[gbracha, 2014-01-02 22:16:03]

We can discuss the liberalization Lasse proposes separately. I'm committing as
it stands.

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.te...
docs/language/dartLangSpec.tex:4600: % Sadly, the info below cannot be computed
efficiently. It would need to be computed at the throw point, since at latte
points it might be destroyed. Native code in calling frames executes relative to
the stack pointer, which therefore needs to be reset as each frame is unwound. 
This means that the
On 2013/11/28 00:31:37, Brian Wilkerson wrote:
> "latte" --> "later"

This is commented out anyway.

https://codereview.chromium.org/93153002/diff/1/docs/language/dartLangSpec.te...
docs/language/dartLangSpec.tex:5084: It is a compile-time error if a name $N$ is
re-exported by a library $L$ and $N$ is  introduced into the export namespace of
$L$ by more than one export, unless all  exports refer to same declaration for
the name $N$.  It is a static warning to export two different libraries with the
same name.
On 2013/11/28 00:31:37, Brian Wilkerson wrote:
> Don't know whether you care, but there's an extra space here.

It's latex, the spaces don't matter.