sigmundch / DEP-member-interceptors

little experiment of using barriers to implement observability
4 stars 4 forks source link

Ensure that this doesn't cause code bloat in dart2js #6

Open jakemac53 opened 9 years ago

jakemac53 commented 9 years ago

In terms of the actual implementation, we need to make sure that there is some path for dart2js to implement this without an unacceptable amount of code bloat. Specifically, I am concerned about having to create a class which extends Member for each field which is annotated, like this example from the getter section:

class _$nameMember extends Member {
  const _$nameMember() : super(#name);
  get(target) => target._$name;
  set(target, value) { target._$name = value; }
  invoke(target, positional, named) =>
      Function.apply(target._$name, positional, named);
}

I think there are a few ways to get around this, but just want to make sure its highlighted as something which should be watched.

sigmundch commented 9 years ago

Yes - given that the code is completely known statically, my hope is that dart2js can avoid creating these objects if possible.

So if you write:

class InterceptorExample {
  get(o, member) => member.get(o) + 1
}

class ExampleUsage {
  @InterceptorExample() int get x => 2;
}

dart2js can do enough inlining to generate the equivalent of this code:

class ExampleUsage {
  int get _x => 2;
  // instead of: int get x => const InterceptorExample().get(this, const _xMember);
  int get x => _x + 1;
}