Adding Daniel as primary reviewer and Scott for owner approval.
1 comment:
File mojo/public/mojom/base/values.mojom:
Patch Set #4, Line 30: // To avoid versioning problems for arc. TODO(sammc): Remove ASAP.
Removed this since it was not referenced anywhere.
To view, visit change 967416. To unsubscribe, or for help writing mail filters, visit settings.
I'd actually prefer to leave the legacy one. The current base::Value typemap uses the legacy semantics using std::unique_ptr, and will make it harder to migrate Mojo things to use the new interface.
I have a CL which already implements the new semantics, but I never got back to updating it after rockot's proposal to just keep typemapped //base constructs under mojo. I'll update that CL and send it out for review, if that works for you?
I'd actually prefer to leave the legacy one. The current base::Value typemap uses the legacy semantics using std::unique_ptr, and will make it harder to migrate Mojo things to use the new interface.
Patch Set 4:
I'd actually prefer to leave the legacy one. The current base::Value typemap uses the legacy semantics using std::unique_ptr, and will make it harder to migrate Mojo things to use the new interface.
I'm confused about what you're suggesting here. Are you saying you want to leave mojo.common.mojom.Value around and have it typemap to std::unique_ptr<base::Value>? I think we still want to get rid of that, but maybe it can be done incrementally once your CL lands.
Or put another way, this CL could be broken into multiple smaller CLs, since it will now aksi have to change C++ code from std::unique_ptr<base::Value> to just base::Value.
I have a CL which already implements the new semantics, but I never got back to updating it after rockot's proposal to just keep typemapped //base constructs under mojo. I'll update that CL and send it out for review, if that works for you?
To view, visit change 967416. To unsubscribe, or for help writing mail filters, visit settings.
Patch Set 4:
Patch Set 4:
I'd actually prefer to leave the legacy one. The current base::Value typemap uses the legacy semantics using std::unique_ptr, and will make it harder to migrate Mojo things to use the new interface.
I'm confused about what you're suggesting here. Are you saying you want to leave mojo.common.mojom.Value around and have it typemap to std::unique_ptr<base::Value>? I think we still want to get rid of that, but maybe it can be done incrementally once your CL lands.
Or put another way, this CL could be broken into multiple smaller CLs, since it will now aksi have to change C++ code from std::unique_ptr<base::Value> to just base::Value.
I have a CL which already implements the new semantics, but I never got back to updating it after rockot's proposal to just keep typemapped //base constructs under mojo. I'll update that CL and send it out for review, if that works for you?
Yes, sorry if that was unclear: the request is to leave the legacy one as-is and incrementally migrate over to the new one.
Patch Set 4:
Patch Set 4:
Patch Set 4:
I'd actually prefer to leave the legacy one. The current base::Value typemap uses the legacy semantics using std::unique_ptr, and will make it harder to migrate Mojo things to use the new interface.
I'm confused about what you're suggesting here. Are you saying you want to leave mojo.common.mojom.Value around and have it typemap to std::unique_ptr<base::Value>? I think we still want to get rid of that, but maybe it can be done incrementally once your CL lands.
Or put another way, this CL could be broken into multiple smaller CLs, since it will now aksi have to change C++ code from std::unique_ptr<base::Value> to just base::Value.
I have a CL which already implements the new semantics, but I never got back to updating it after rockot's proposal to just keep typemapped //base constructs under mojo. I'll update that CL and send it out for review, if that works for you?Yes, sorry if that was unclear: the request is to leave the legacy one as-is and incrementally migrate over to the new one.
Waiting for this to be resolved before continuing.
Patch Set 4:
Patch Set 4:
Patch Set 4:
Patch Set 4:
I'd actually prefer to leave the legacy one. The current base::Value typemap uses the legacy semantics using std::unique_ptr, and will make it harder to migrate Mojo things to use the new interface.
I'm confused about what you're suggesting here. Are you saying you want to leave mojo.common.mojom.Value around and have it typemap to std::unique_ptr<base::Value>? I think we still want to get rid of that, but maybe it can be done incrementally once your CL lands.
Or put another way, this CL could be broken into multiple smaller CLs, since it will now aksi have to change C++ code from std::unique_ptr<base::Value> to just base::Value.
I have a CL which already implements the new semantics, but I never got back to updating it after rockot's proposal to just keep typemapped //base constructs under mojo. I'll update that CL and send it out for review, if that works for you?Yes, sorry if that was unclear: the request is to leave the legacy one as-is and incrementally migrate over to the new one.
Waiting for this to be resolved before continuing.
By continuing I mean reviewing.
Patch Set 4:
Patch Set 4:
Patch Set 4:
I'd actually prefer to leave the legacy one. The current base::Value typemap uses the legacy semantics using std::unique_ptr, and will make it harder to migrate Mojo things to use the new interface.
I'm confused about what you're suggesting here. Are you saying you want to leave mojo.common.mojom.Value around and have it typemap to std::unique_ptr<base::Value>? I think we still want to get rid of that, but maybe it can be done incrementally once your CL lands.
Or put another way, this CL could be broken into multiple smaller CLs, since it will now aksi have to change C++ code from std::unique_ptr<base::Value> to just base::Value.
I have a CL which already implements the new semantics, but I never got back to updating it after rockot's proposal to just keep typemapped //base constructs under mojo. I'll update that CL and send it out for review, if that works for you?Yes, sorry if that was unclear: the request is to leave the legacy one as-is and incrementally migrate over to the new one.
Would the migration to base::Value be outside the scope of this bug (https://bugs.chromium.org/p/chromium/issues/detail?id=799482) and in scope of https://bugs.chromium.org/p/chromium/issues/detail?id=646113?
In this case I will abandon this CL.
I think I would count it as part of this bug, but I can certainly help with conversions. We could save base::Value usage conversion for last.
Oksana Zhuravlova abandoned this change.
To view, visit change 967416. To unsubscribe, or for help writing mail filters, visit settings.