Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > state of an object in setUp() of junit TestCase

Reply
Thread Tools

state of an object in setUp() of junit TestCase

 
 
markspace
Guest
Posts: n/a
 
      11-01-2010
On 11/1/2010 2:00 PM, Tom Anderson wrote:

> Right. But the constructor also gets run before each individual test,



Huh, thanks for pointing that out, I didn't realize that.

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      11-01-2010
On 11/01/2010 04:29 PM, Jim Janney wrote:
> markspace<(E-Mail Removed)> writes:
>
>> On 10/30/2010 9:39 AM, Stanimir Stamenkov wrote:
>>
>>>> ... Relying on such default values, however, is generally
>>>> considered bad programming style.
>>>
>>> I don't completely agree with the given statement, but then I can't come
>>> up with arguments on any side. What do you think about it?

>>
>>
>> Lew's comment that an explicit initialization requires a second,
>> redundant and useless initialization is enough to counter Oracle's
>> statement.

>
> Premature and probably pointless micro-optimization. I'm having
> trouble imagining a class where this could make a measurable
> difference in execution speed or a meaningful difference in code size.


If optimization were the purpose, then your comment would apply.

> First make it readable. Then make it right. Then, as an optional
> step if that turns out to be necessary, worry about making it fast.


No one is worrying about making initialization faster here. What we're saying
is that an unnecessary step (i.e., the redundant initialization) should not
happen unless it actually turns out to be necessary, and that that is never in
the case of member variable initialization to default ("zero-like") values.

>> I'd say precisely the opposite. The default values are 100%
>> guaranteed and deterministic, there's no reason not to rely on them,
>> and it's certainly not bad style. I'm sorry for whoever wrote that
>> line in the tutorial but I think they went off some place unknown to
>> most professionals.

>
> Professionals understand that readability normally trumps minor
> efficiency gains. We can debate which style is clearer, but redundant
> code shouldn't be a concern.


Anyone who claims to program in Java that cannot read the default
initialization of member variables needs to work where the primary skill is to
respond to a flashing orange light on the cash register by asking their
customer, "Would you like fries with that?"

markspace's point that you did not answer was that use of default
initialization for member variables is not less readable and that it obviates
the need for explicit "zero-like" initialization - not because the extra
initialization is slower, a point no one made, but because it is not
necessary. It's the "extra" that's bad, not the speed.

So you refuted a claim not made and let stand the claim actually made.

--
Lew
 
Reply With Quote
 
 
 
 
Jim Janney
Guest
Posts: n/a
 
      11-02-2010
Lew <(E-Mail Removed)> writes:

> On 11/01/2010 04:29 PM, Jim Janney wrote:
>> markspace<(E-Mail Removed)> writes:
>>
>>> On 10/30/2010 9:39 AM, Stanimir Stamenkov wrote:
>>>
>>>>> ... Relying on such default values, however, is generally
>>>>> considered bad programming style.
>>>>
>>>> I don't completely agree with the given statement, but then I can't come
>>>> up with arguments on any side. What do you think about it?
>>>
>>>
>>> Lew's comment that an explicit initialization requires a second,
>>> redundant and useless initialization is enough to counter Oracle's
>>> statement.

>>
>> Premature and probably pointless micro-optimization. I'm having
>> trouble imagining a class where this could make a measurable
>> difference in execution speed or a meaningful difference in code size.

>
> If optimization were the purpose, then your comment would apply.
>
>> First make it readable. Then make it right. Then, as an optional
>> step if that turns out to be necessary, worry about making it fast.

>
> No one is worrying about making initialization faster here. What
> we're saying is that an unnecessary step (i.e., the redundant
> initialization) should not happen unless it actually turns out to be
> necessary, and that that is never in the case of member variable
> initialization to default ("zero-like") values.
>
>>> I'd say precisely the opposite. The default values are 100%
>>> guaranteed and deterministic, there's no reason not to rely on them,
>>> and it's certainly not bad style. I'm sorry for whoever wrote that
>>> line in the tutorial but I think they went off some place unknown to
>>> most professionals.

>>
>> Professionals understand that readability normally trumps minor
>> efficiency gains. We can debate which style is clearer, but redundant
>> code shouldn't be a concern.

>
> Anyone who claims to program in Java that cannot read the default
> initialization of member variables needs to work where the primary
> skill is to respond to a flashing orange light on the cash register by
> asking their customer, "Would you like fries with that?"
>
> markspace's point that you did not answer was that use of default
> initialization for member variables is not less readable and that it
> obviates the need for explicit "zero-like" initialization - not
> because the extra initialization is slower, a point no one made, but
> because it is not necessary. It's the "extra" that's bad, not the
> speed.


You are correct that I misunderstood the intent of the original
objection. I will plead that it was a natural mistake, since the true
intent is, if anything, even less sensible.

Initializing a field to its default value serves as a useful
indication that the correct operation of the class depends on that
field having that value at that point. Relying on the default
initializer, even though it has the same effect a run time, does not
convey the same information to the reader, since the default
initializers are always applied whether they're needed or not. To me,
omitting the initalizer suggests that the field will receive its real
value sometime later, in a constructor or through some form of delayed
evaluation. It's not a question of understanding the language but of
making the programmer's intentions clear, without creating unnecessary
puzzles.

--
Jim Janney
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-02-2010
Jim Janney wrote:
> Initializing a field to its default value serves as a useful
> indication that the correct operation of the class depends on that
> field having that value at that point. *Relying on the default
>


That same point was raised upthread.

> initializer, even though it has the same effect a run time, does not
> convey the same information to the reader, since the default
> initializers are always applied whether they're needed or not. *To me,
> omitting the initalizer suggests that the field will receive its real
> value sometime later, in a constructor or through some form of delayed
> evaluation. *It's not a question of understanding the language but of
> making the programmer's intentions clear, without creating unnecessary
> puzzles.
>


This is precisely the point that markspace was refuting when you
answered him. Welcome to the conversation.

He was saying that adding the redundant initializer does not add that
additional information you just cited, because the action of default
initializers in Java is deterministic and introductory knowledge for
Java programmers. Since all Java programmers know about default
member-variable initialization, adding the second, redundant
initialization does not convey additional information. Therefore the
extra step really is extra, buying nothing, and should be avoided.

I was the one who brought up the idea that there is stylistic
information added by the second initialization, but I do agree with
markspace that the value of that documentation is questionable at
best.

--
Lew
 
Reply With Quote
 
Jim Janney
Guest
Posts: n/a
 
      11-02-2010
Lew <(E-Mail Removed)> writes:

> Jim Janney wrote:
>> Initializing a field to its default value serves as a useful
>> indication that the correct operation of the class depends on that
>> field having that value at that point. *Relying on the default
>>

>
> That same point was raised upthread.
>
>> initializer, even though it has the same effect a run time, does not
>> convey the same information to the reader, since the default
>> initializers are always applied whether they're needed or not. *To me,
>> omitting the initalizer suggests that the field will receive its real
>> value sometime later, in a constructor or through some form of delayed
>> evaluation. *It's not a question of understanding the language but of
>> making the programmer's intentions clear, without creating unnecessary
>> puzzles.
>>

>
> This is precisely the point that markspace was refuting when you
> answered him. Welcome to the conversation.


Except that as a stylistic issue, which is how the question was
framed, his point is not a refutation but merely a technical
irrelevance. Information that is redundant to the compiler may yet be
useful to the reader. Good programming style is about effective
communication, not parading one's mastery of the language.

Deliberately omitting information that is useful to the reader, simply
because one knows the compiler can do without it, is not good
programming style.

--
Jim Janney
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      11-02-2010
In article
<(E-Mail Removed)>,
Lew <(E-Mail Removed)> wrote:

> Jim Janney wrote:
> > Initializing a field to its default value serves as a useful
> > indication that the correct operation of the class depends on that
> > field having that value at that point. *Relying on the default
> >

>
> That same point was raised upthread.
>
> > initializer, even though it has the same effect a run time, does
> > not convey the same information to the reader, since the default
> > initializers are always applied whether they're needed or not. *To
> > me, omitting the initalizer suggests that the field will receive
> > its real value sometime later, in a constructor or through some
> > form of delayed evaluation. *It's not a question of understanding
> > the language but of making the programmer's intentions clear,
> > without creating unnecessary puzzles.
> >

>
> This is precisely the point that markspace was refuting when you
> answered him. Welcome to the conversation.
>
> He was saying that adding the redundant initializer does not add that
> additional information you just cited, because the action of default
> initializers in Java is deterministic and introductory knowledge for
> Java programmers. Since all Java programmers know about default
> member-variable initialization, adding the second, redundant
> initialization does not convey additional information. Therefore the
> extra step really is extra, buying nothing, and should be avoided.
>
> I was the one who brought up the idea that there is stylistic
> information added by the second initialization, but I do agree with
> markspace that the value of that documentation is questionable at
> best.


As a longtime student of strongly typed languages without default
initialization, I empathize with the desire for clarity that an
explicit initializer offers. But Java is Java, and I hate redundant
cycles more:

$ make run
cat Allocate.java
public class Allocate {
int i;
}
javac Allocate.java
javap -c Allocate
Compiled from "Allocate.java"
public class Allocate extends java.lang.Object{
int i;

public Allocate();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>")V
4: return

}

$ make run
cat Allocate.java
public class Allocate {
int i = 0;
}
javac Allocate.java
javap -c Allocate
Compiled from "Allocate.java"
public class Allocate extends java.lang.Object{
int i;

public Allocate();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>")V
4: aload_0
5: iconst_0
6: putfield #2; //Field i:I
9: return

}

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
 
Reply With Quote
 
Jim Janney
Guest
Posts: n/a
 
      11-02-2010
"John B. Matthews" <(E-Mail Removed)> writes:

> In article
> <(E-Mail Removed)>,
> Lew <(E-Mail Removed)> wrote:
>
>> Jim Janney wrote:
>> > Initializing a field to its default value serves as a useful
>> > indication that the correct operation of the class depends on that
>> > field having that value at that point. *Relying on the default
>> >

>>
>> That same point was raised upthread.
>>
>> > initializer, even though it has the same effect a run time, does
>> > not convey the same information to the reader, since the default
>> > initializers are always applied whether they're needed or not. *To
>> > me, omitting the initalizer suggests that the field will receive
>> > its real value sometime later, in a constructor or through some
>> > form of delayed evaluation. *It's not a question of understanding
>> > the language but of making the programmer's intentions clear,
>> > without creating unnecessary puzzles.
>> >

>>
>> This is precisely the point that markspace was refuting when you
>> answered him. Welcome to the conversation.
>>
>> He was saying that adding the redundant initializer does not add that
>> additional information you just cited, because the action of default
>> initializers in Java is deterministic and introductory knowledge for
>> Java programmers. Since all Java programmers know about default
>> member-variable initialization, adding the second, redundant
>> initialization does not convey additional information. Therefore the
>> extra step really is extra, buying nothing, and should be avoided.
>>
>> I was the one who brought up the idea that there is stylistic
>> information added by the second initialization, but I do agree with
>> markspace that the value of that documentation is questionable at
>> best.

>
> As a longtime student of strongly typed languages without default
> initialization, I empathize with the desire for clarity that an
> explicit initializer offers. But Java is Java, and I hate redundant
> cycles more:
>
> $ make run
> cat Allocate.java
> public class Allocate {
> int i;
> }
> javac Allocate.java
> javap -c Allocate
> Compiled from "Allocate.java"
> public class Allocate extends java.lang.Object{
> int i;
>
> public Allocate();
> Code:
> 0: aload_0
> 1: invokespecial #1; //Method java/lang/Object."<init>")V
> 4: return
>
> }
>
> $ make run
> cat Allocate.java
> public class Allocate {
> int i = 0;
> }
> javac Allocate.java
> javap -c Allocate
> Compiled from "Allocate.java"
> public class Allocate extends java.lang.Object{
> int i;
>
> public Allocate();
> Code:
> 0: aload_0
> 1: invokespecial #1; //Method java/lang/Object."<init>")V
> 4: aload_0
> 5: iconst_0
> 6: putfield #2; //Field i:I
> 9: return
>
> }


This is precisely the point that Lew claimed no one was making. I've
already explained why I disagree: readability normally trumps minor
efficiency gains. There are exceptions, of course, but not many.

Out of curiousity, what does the hotspot compiler do with code like
this?

--
Jim Janney
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      11-03-2010
In article <(E-Mail Removed)>,
Jim Janney <(E-Mail Removed)> wrote:
[...]
> > As a longtime student of strongly typed languages without default
> > initialization, I empathize with the desire for clarity that an
> > explicit initializer offers. But Java is Java, and I hate redundant
> > cycles more:
> >

[...]
> > public class Allocate {
> > int i;
> > }

[...]
> > public Allocate();
> > Code:
> > 0: aload_0
> > 1: invokespecial #1; //Method java/lang/Object."<init>")V
> > 4: return
> > }

[...]
> > public class Allocate {
> > int i = 0;
> > }

[...]
> > public Allocate();
> > Code:
> > 0: aload_0
> > 1: invokespecial #1; //Method java/lang/Object."<init>")V
> > 4: aload_0
> > 5: iconst_0
> > 6: putfield #2; //Field i:I
> > 9: return
> > }

>
> This is precisely the point that Lew claimed no one was making. I've
> already explained why I disagree: readability normally trumps minor
> efficiency gains. There are exceptions, of course, but not many.


Subjectively, I came to feel that "int i = 0" was me transliterating
Pascal into Java, while "int i" began to seem more readable as a means
of obtaining the default initial value specified by the JLS.

> Out of curiousity, what does the hotspot compiler do with code like
> this?


My limited understanding is that HotSpot tries to detect and optimize
frequently used code. I'd guess the result depends on how frequently the
constructor is called. OTOH, if I don't write duplicate code, HotSpot
doesn't have to optimize it.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-03-2010
Jim Janney wrote:
> Except that as a stylistic issue, which is how the question was
> framed, his point is not a refutation but merely a technical
> irrelevance. Information that is redundant to the compiler may yet be
> useful to the reader. Good programming style is about effective
> communication, not parading one's mastery of the language.
>
> Deliberately omitting information that is useful to the reader, simply
> because one knows the compiler can do without it, is not good
> programming style.


That would be valid if the omitted information were useful to the reader. In
the case of default values for member variables, the redundant initialization
is not useful to the reader. It simply restates what every Java programmer
already knows. Useless. Therefore, deliberately not adding the extra
redundant unnecessary repetitive zero-net-effect initialization (which is
different from omitting something that should be there) is good programming style.

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-03-2010
On 11/02/2010 05:55 PM, Jim Janney wrote:
> "John B. Matthews"<(E-Mail Removed)> writes:
>
>> In article
>> <(E-Mail Removed)>,
>> Lew<(E-Mail Removed)> wrote:
>>
>>> Jim Janney wrote:
>>>> Initializing a field to its default value serves as a useful
>>>> indication that the correct operation of the class depends on that
>>>> field having that value at that point. Relying on the default
>>>>
>>>
>>> That same point was raised upthread.
>>>
>>>> initializer, even though it has the same effect a run time, does
>>>> not convey the same information to the reader, since the default
>>>> initializers are always applied whether they're needed or not. To
>>>> me, omitting the initalizer suggests that the field will receive
>>>> its real value sometime later, in a constructor or through some
>>>> form of delayed evaluation. It's not a question of understanding
>>>> the language but of making the programmer's intentions clear,
>>>> without creating unnecessary puzzles.
>>>>
>>>
>>> This is precisely the point that markspace was refuting when you
>>> answered him. Welcome to the conversation.
>>>
>>> He was saying that adding the redundant initializer does not add that
>>> additional information you just cited, because the action of default
>>> initializers in Java is deterministic and introductory knowledge for
>>> Java programmers. Since all Java programmers know about default
>>> member-variable initialization, adding the second, redundant
>>> initialization does not convey additional information. Therefore the
>>> extra step really is extra, buying nothing, and should be avoided.
>>>
>>> I was the one who brought up the idea that there is stylistic
>>> information added by the second initialization, but I do agree with
>>> markspace that the value of that documentation is questionable at
>>> best.

>>
>> As a longtime student of strongly typed languages without default
>> initialization, I empathize with the desire for clarity that an
>> explicit initializer offers. But Java is Java, and I hate redundant
>> cycles more:
>>
>> $ make run
>> cat Allocate.java
>> public class Allocate {
>> int i;
>> }
>> javac Allocate.java
>> javap -c Allocate
>> Compiled from "Allocate.java"
>> public class Allocate extends java.lang.Object{
>> int i;
>>
>> public Allocate();
>> Code:
>> 0: aload_0
>> 1: invokespecial #1; //Method java/lang/Object."<init>")V
>> 4: return
>>
>> }
>>
>> $ make run
>> cat Allocate.java
>> public class Allocate {
>> int i = 0;
>> }
>> javac Allocate.java
>> javap -c Allocate
>> Compiled from "Allocate.java"
>> public class Allocate extends java.lang.Object{
>> int i;
>>
>> public Allocate();
>> Code:
>> 0: aload_0
>> 1: invokespecial #1; //Method java/lang/Object."<init>")V
>> 4: aload_0
>> 5: iconst_0
>> 6: putfield #2; //Field i:I
>> 9: return
>>
>> }

>
> This is precisely the point that Lew claimed no one was making. I've


Correctly.

> already explained why I disagree: readability normally trumps minor
> efficiency gains. There are exceptions, of course, but not many.


If your idea improved readability, I'd agree with you.

But it doesn't, so I don't.

> Out of curiousity, what does the hotspot compiler do with code like
> this?


It is forbidden to optimize the extra initialization. It is required to
perform the redundant initialization. It must initialize to the default value
implicitly, then at the correct point of the initialization sequence execute
the explicit initialization. It is not permitted to do otherwise.

Wow, I must have really improved readability in that paragraph!

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Differerence between Test::Unit::TestCase and RUNIT::TestCase Scott Ruby 1 08-20-2005 08:49 PM
unittest.TestCase, lambda and __getitem__ Steven Bethard Python 7 09-14-2004 02:43 PM
Create TestCase with WSAD on EJB Memi Lavi Java 0 08-05-2004 03:23 PM
Computing test methods in unittest.TestCase Jan Decaluwe Python 2 03-02-2004 06:33 PM
standard struts testcase failed ? Charlie Java 1 10-16-2003 04:58 AM



Advertisments