Browse interfacekit: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date

[interfacekit] Re: Fwd: BAutolock

From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
To: interfacekit@xxxxxxxxxxxxx
Date: Thu, 11 Sep 2003 16:15:39 +0200 CEST

"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> This is a forward from Waldemar - Erik, could you please open up this 
> list? :-)

See? Now I even have to answer to my own mails :)

Waldemar wrote:
> > Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > On 2003-09-11 at 07:24:38 [+0200], Waldemar Kornewald wrote:
> > [...]
> > > > bool Relock()
> > > > This locks the BLocker/BLooper object if it is not already 
> > > > locked
> > > > by this
> > > > object. This method is called by the constructor(s).
> > I think the name of this method is misleading, it should just be 
> > Lock() IMO.
> Okay. I hope that the devs do not think a second Lock() will lock the
> BLocker twice.

Will Unlock() unlock a BLocker twice?
It's all a matter of documentation - and I think a Relock() does even 
more appears to lock twice (cause it would seem to relock the locker) 
:)

> > > > void SetLockStatus(bool lockStatus)
> > But this one is pretty much useless in my opinion.
> > I would rather have Set() and Unset() pairs (I am frequently using 
> > a
> > method Keep() in similar things, though).
> > Set() could have a parameter that specifies if the BLocker is 
> > already
> > locked or not, Unset() would not unlock it on destruction. That 
> > would
> > allow it to use in almost all locking cases.
> First of all: what does Keep() do?

It would prevent the BLocker from being unlocked upon destruction of 
the BAutolock. I just mentioned it because that's what I am personally 
using in similar cases.

> I think SetLockStatus() does the same as your Set().
> Set(true) is equivalent to SetLockStatus(true), but I prefer my 
> naming. 
> :)

No, it would come along with an empty constructor, and could be used 
like this, btw, it should even be called SetTo():

{
        BAutolocker locker;
        if (isFromWindow)
                locker.SetTo(Window());
        else
                locker.SetTo(Application());

        ....
}

We could even have it like this:
        SetTo(BLocker &locker, bool isAlreadyLocked = false);

> Why do we need Unset()? Set(false) (or SetLockStatus(false)) already 
> says that it does not need to be unlocked, does it?

It does a bit more, you could do things like:

BAutolocker locker(lockA);

if (...) {
        locker.Unset();
        locker.SetTo(lockB);
}

Although it looks like it's meaning is not even as clear as I thought 
it would be, because you don't know if Unset() unlocks the BLocker or 
not.
I would think Unset() defaults to unlock the BLocker, maybe it could 
have a default parameter like this:
        Unset(bool unlock = true);

Then it could be the same as my Keep() when using it like this:
        Unset(false);

> What about replacing it with a more general template? On the other 
> hand, who
> says Lock() returns status_t (or bool) in all classes? Your own 
> Benaphore
> class might return another value.

Why should it return another value?

Adios...
   Axel.

References:

[interfacekit] Re: Fwd: BAutolock
From: Axel Dörfler

[interfacekit] Re: Fwd: BAutolock

Other related posts: