Re: this.wait( sleep );
From: Jon Skeet (skeet_at_pobox.com)
Date: 02/26/04
- Next message: Jon Skeet: "Re: this.wait( sleep );"
- Previous message: Andrew Thompson: "Re: parsing a string using Stringtokenzier"
- In reply to: Ricardo: "Re: this.wait( sleep );"
- Next in thread: Ricardo: "Re: this.wait( sleep );"
- Reply: Ricardo: "Re: this.wait( sleep );"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 26 Feb 2004 16:12:26 -0000
Ricardo <spam@spam.spam> wrote:
> > I really don't think it's necessary though. Being static, if anyone
> > *is* confused, they'll *know* they're confused immediately, and can
> > consult the documentation to become unconfused. With your way of
> > writing code, people are likely to get confused and *stay* confused
> > about what Thread.sleep does.
>
> I'll borrow your example from below..
>
> Thread t = new Thread (....);
> t.start();
> t.sleep(500);
>
> As long as this compiles, then the problem exists. There is nothing that
> would stop anyone from writing it. The confusion is not the result from
> seeing Thread.currentThread().sleep(..), but from having start,
> interrupt, yield, sleep, ... as methods in the same class that can do
> very unpredictable things..
They don't do unpredictable things at all. The confusion is the result
of being able to call static methods as if they were instance methods,
which then leads people to think that they operate on the instance
they're talking about.
> Now, let's put the novice hats on and compare *readability*:
>
> // A
> Thread t = new Thread (....);
> t.start();
> Thread.currentThread().sleep(500);
>
> // B
> Thread t = new Thread (....);
> t.start();
> Thread.sleep(500);
>
> Now, consider renaming t to thread..
>
> // C (common? oh yes)
> Thread thread = new Thread (....);
> thread.start();
> Thread.sleep(500);
>
> Does A encourages t.sleep()? I don't see that.
Novice programmer reads your code. He hasn't encountered Thread.sleep
before. He reads the code and thinks, "Ah, Thread.sleep must be an
instance method which sends whatever thread it's called on to sleep."
Later, when he's writing some other code where he (foolishly) wants to
make another thread pause, he calls t.sleep() and then gets confused
when it makes "the wrong thread" sleep.
> However, A is by far the most readable.
In your view - not in mine. It gives a false impression of the nature
of the Thread.sleep call, in my view - and that doesn't add to
readability, it reduces it.
> > It would give the right impression about what is happening, but the
> > wrong impression about what the Thread.sleep method itself does. Ask
> > yourself which convention is more likely to lead to the reader
> > eventually writing code such as:
> >
> > Thread t = new Thread (....);
> > t.start();
> > t.sleep(500);
>
> And that's the heart of the issue..
> If it's a way to learn the API, you score all the points.
If the programmer knows the API already, then it's irrelevant, as
they'll know that Thread.sleep makes the current thread sleep.
> However, I believe strongly that this class in particular is critical
> enough that I'd make sure that sleep in only called using a reference to
> currentThread.
*You* might do that - but will everyone else who's read your code and
got the wrong end of the stick?
> > Actually, it's a common design for thread classes, I believe - static
> > methods apply to the current thread, because that's the only thread it
> > makes sense for them to apply to. Instance methods apply to the method
> > they're called on. That's applied consistently - contrary to your post
> > a while ago which claimed that isInterrupted gives information about
> > the current thread, it gives information about the thread instance it's
> > called on.
>
> You're referencing the following:
>
> >>> ....
> >>> resume() /* DEPREATED, instance method */
> >>> interrupt() /* instance method */
> >>> interrupted() /* static method, Current Thread */
> >>> isInterrupted() /* instance method, Current Thread */
>
> and that was a bad comment, resulted from cut+paste from previous line.
> It should've been: "/* instance method */". Debugging comments is far
> more difficult than debugging code.
Right. However, it does mean that the Thread class is entirely
consistent.
> However, you did touch another call that you find debated in lunch rooms:
>
> Thread.interrupted()
>
> vs.
>
> Thread.currentThread().isInterrupted()
>
> I do prefer the latter (to the surprise of few), and hope this won't be
> questioned by the static methods police..
I don't particularly mind either of them. What I *would* object to is
Thread.currentThread().interrupted()
as again, that gives a false impression.
> > I don't find it in the least bit confusing - but I'm sure I would if I
> > were a new programmer who encountered code which called the static
> > method via an instance reference.
>
> Jon, maybe you don't find it confusing, but it is a nasty design. At
> any given point, you could call start, stop, pause, interrupt, sleep,
> yield, all as methods in the same class, all are legal when called using
> an instance. That would certainly not be your design.
My design would be for the language to forbid calling
Thread.currentThread().sleep() in the first place (as C# does, btw).
>From that starting point, I see nothing particularly wrong in the
design of the Thread class. The "all static methods operate on the
current thread; all instance methods operate on the instance thread"
rule is hardly difficult to learn.
-- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
- Next message: Jon Skeet: "Re: this.wait( sleep );"
- Previous message: Andrew Thompson: "Re: parsing a string using Stringtokenzier"
- In reply to: Ricardo: "Re: this.wait( sleep );"
- Next in thread: Ricardo: "Re: this.wait( sleep );"
- Reply: Ricardo: "Re: this.wait( sleep );"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
