On Wed, Aug 7, 2013 at 10:54 AM, Darin Fisher <da...@chromium.org> wrote:I don't recall reaching a conclusion to phase it out. It's a useful
> I thought we had decided to phase out SupportsWeakPtr. Did that idea
> fizzle?
>
> -Darin
>
class/abstraction, but as mentioned, it makes more sense within inner
classes / implementation helpers / implementation classes - just not
on 'public' classes.
>
> On Wed, Aug 7, 2013 at 10:51 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>>
>> On Wed, Aug 7, 2013 at 8:25 AM, Jeffrey Yasskin <jyas...@chromium.org>
>> wrote:
>> > On Wed, Aug 7, 2013 at 2:25 AM, William Chan (陈智昌)
>> > <will...@chromium.org> wrote:
>> >> On Wed, Aug 7, 2013 at 2:23 AM, William Chan (陈智昌)
>> >> <will...@chromium.org>
>> >> wrote:
>> >>>
>> >>> I don't have time to write up a rant on why NotificationService is
>> >>> bad,
>> >>> but I'm pleased to see there's a lot of momentum here so I probably
>> >>> don't
>> >>> need to. So, +1 on removing NotificationService.
>> >>>
>> >>> On Wed, Aug 7, 2013 at 1:40 AM, Drew Wilson <atwi...@chromium.org>
>> >>> wrote:
>> >>>>
>> >>>> In the current world we use notifications. In the new world we would:
>> >>>>
>> >>>> a) Change class B so it SupportsWeakPtr<>.
>> >>>
>> >>>
>> >>> Please avoid using WeakPtr, and especially SupportsWeakPtr, if
>> >>> possible.
>> >>
>> >>
>> >> Er, quick clarification on this one, I mean avoid passing WeakPtr<T>
>> >> outside
>> >> of T* (as opposed to using the WeakPtr<T> internally to T*, in which
>> >> case
>> >> WeakPtrFactory is much better).
>> >
>> > In many cases, we wind up with an apparent choice between
>> > SupportsWeakPtr (or its equivalent) and an Observer method
>> > ObserveeDestroyed(), which reimplements the functionality of WeakPtr.
>> > IMO, the dedicated class is easier to read and results in simpler
>> > code, so we should prefer it.
>> >
>> > I agree that designing simple "X outlives Y and has no pointers to Y"
>> > relationships is better (so we don't need either), but we need to make
>> > that the rule. We shouldn't discourage WeakPtr (the simplest way of
>> > coping with complex lifetimes) while allowing more complex ways of
>> > doing the same thing.
>> >
>> > Jeffrey
>> >
>> > P.S. Re Drew's "I want to get a WeakPtr to B", I believe Will's point
>> > is that you _shouldn't_ "want to get a WeakPtr to B". :)
>>
>> From discussions with Will on this point, I think the choice between
>> SupportsWeakPtr and ObserveeDestroyed() are a false choice - what you
>> really what is contractual lifetimes between objects. I also think
>> using WeakPtr<> to simulate the FooDestroyed case is actually fairly
>> dangerous, in that WeakPtr<> has additional pre-conditions that a
>> *Destroyed observer doesn't necessarily have.
>>
>> SupportsWeakPtr (which exposes your WeakPtr to arbitrary callers) is,
>> arguably, as much a design anti-pattern as public RefCounting. It's
>> not that WeakPtrs are inherently bad, just like RefCounting isn't
>> inherently bad, but it can make it much more difficult to reason about
>> the correctness of the code.
>>
>> If you're going to use WeakPtrs (and they're extremely handy), the
>> 'preferred' approach is that you encapulsate the WeakPtrFactory within
>> your class - so that there's a single point at which WeakPtrs can be
>> obtained - within the implementation file. Using base::Bind() and
>> friends to create 'cancellable callbacks' lets you have situations
>> where A outlives B, but B needs to do something on A and may disappear
>> while A is doing it.
>>
>> SupportsWeakPtr<> as a design pattern should only really be used in
>> private classes / implementation classes, because it offers the same
>> design constraint as having a (private) WeakPtrFactory and no (public)
>> way to vend WeakPtrs - the WeakPtr lifecycle is kept entirely within a
>> file and can be reasoned about for correctness (eg: thread affinity,
>> lifetimes, etc)
>
>
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Oh, good point, that's on WeakPtr itself. :-/
This is a minor issue, but WeakPtrFactory costs 1 more word of memory
than SupportsWeakPtr.