lib/testing/mixins.dart - Issue 2086253002: Allow application of external mixins to generated dart protos.

Side by Side Diff

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Side by Side Diff: lib/testing/mixins.dart

Issue 2086253002: Allow application of external mixins to generated dart protos. (Closed) Base URL: https://github.com/dart-lang/dart-protoc-plugin.git@master

Patch Set: Add support for mixins in protos. Created 4 years, 6 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
(Empty)
	1 abstract class Mixin1 {
	skybrian 2016/06/22 20:29:52 Can we put this file under "test" instead of in "l Can we put this file under "test" instead of in "lib/testing"? I think we can get away with a relative import in the .proto file: "../../test/mixins.dart" frederikmutzel 2016/06/23 12:30:16 I'd really prefer to use a package import here. Re Show quoted text On 2016/06/22 20:29:52, skybrian wrote: > Can we put this file under "test" instead of in "lib/testing"? > > I think we can get away with a relative import in the .proto file: > "../../test/mixins.dart" > I'd really prefer to use a package import here. Reasons: - It makes it easier to move the generated dart file - Clients are more likely to use package imports (and they probably should), so it would be a better example - Internally, it seems like people prefer putting only tests in test/ and testing support libraries in testing/ (although protobuf doesn't seem to do that) I'm generally not a fan of relative imports, tooling seems to handle package imports much better as well when refactoring.
	2 String get overriddenString => "mixin1";

	3

	4 String get interfaceString;

	5 set interfaceString(String string);

	6 bool hasInterfaceString();

	7 }

	8

	9 abstract class Mixin2 {

	10 String get overriddenString => "mixin2";

	11

	12 bool hasOverriddenHasMethod() => false;

	13 }

OLD	NEW

« lib/message_generator.dart ('K') | « lib/src/dart_options.pb.dart ('k') | pubspec.yaml » ('j') | test/mixin_test.dart » ('J')