If the semantics difference between TemporaryRef and already_AddRefed are the main factor blocking us here, could we at least make progress by temporarily having the two coexist, i.e. a transition plan roughly as follows:
1) Introduce a nsTemporaryRef behaving like TemporaryRef but cooperating with nsRefPtr. 2) Mechanically port from RefPtr+TemporaryRef to nsRefPtr+nsTemporaryRef 3) Remove RefPtr and TemporaryRef 4) Be left with some nsTemporaryRef usage; maybe manually go over it and switch to already_AddRefed, or maybe live with it. Benoit 2014-05-12 19:48 GMT-04:00 Mike Hommey <m...@glandium.org>: > On Mon, May 12, 2014 at 04:46:18PM -0700, Kyle Huey wrote: > > On Mon, May 12, 2014 at 2:46 PM, Mike Hommey <m...@glandium.org> wrote: > > > On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: > > >> We should get rid of RefPtr, just like we did the MFBT refcounting > classes. > > >> > > >> The main thing stopping a mechanical search and replace is that the > > >> two smart pointers have different semantics around > > >> already_AddRefed/TemporaryRef :( > > > > > > Another part of the problem is third party code that uses RefPtr. > > > > > > Mike > > > > Are you referring to moz2d or something else? > > I'm referring to the webkit/chromium-imported code that needs it as a > replacement for wtf::RefPtr (aiui). > > Mike > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
