Skip to content

Can @patch be public? #842

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

Closed
pouloghost opened this issue Feb 17, 2020 · 3 comments
Closed

Can @patch be public? #842

pouloghost opened this issue Feb 17, 2020 · 3 comments
Labels
request Requests to resolve a particular developer problem

Comments

@pouloghost
Copy link

I have a cli command to convert gson java file to dart file. i.e.

public class Foo {
  @SerializeName('aaa')
  public String aaa;
}

to

class Foo {
  Foo({this.aaa});

  String aaa;

  ...fromJson...
  ...toJson...
}

Some modifications may be applied to the generated dart, i.e. add a method. Meanwhile dart file should be updated by re-generate using cli, whenever java file gets updated.

Adding a method each re-generation could be avoided by using external and @patch, but @patch is private to dart:_internal.

On external and @patch only, a keyword can only be used with a private meta looks quite strange to me.

@pouloghost pouloghost added the request Requests to resolve a particular developer problem label Feb 17, 2020
@pouloghost
Copy link
Author

I've using mixin and quite a lot tweak in my cli to work around this.

@lrhn
Copy link
Member

lrhn commented Feb 17, 2020

The syntax external is generally available so that any Dart source tool can handle partially specified declarations. There is no inherent meaning to the marker except that the meaning of the function is supplied in a non-source based way, which obviously means that a compiler needs to know what to do with it.

Currently it's only used by the platform libraries because that's the only external functions that the platform compilers know how to provide an implementation for.

The @patch marker and patch files is not public. It's just how the SDK developers have agreed to structure our implementations, and it's not designed to be a public-facing feature (it's cumbersome, pedantic and fragile, but that only affects a few people, so it's OK in the grand scale of things).

If you look at the dart:ffi library, that's another place where a compiler introduces implementation from a non-source-code source. It should probably be using external markers on its fields (which is why we consider allowing external fields now (#44), something which was previously not needed because a few internal people cumbersomely having to write individual getters and setters was considered OK).

So: Definite no to exposing @patch because we do not want to expose the patching operation to user code. You might want something like partial classes (#678).

@pouloghost
Copy link
Author

Partial class seems to be a much better solution. Hope partial class could be available soon. Thanks for reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Requests to resolve a particular developer problem
Projects
None yet
Development

No branches or pull requests

2 participants