«

Arne Vajhøj wrote:
> lewbloch wrote:
>> Chad wrote:
>>> The following code, which is taken from one of my school books,
>>> displays 4 different boxes inside a gui [sic]
>>>
>>> import java.awt.*;
>>> import javax.swing.*;
>>>
>>> public class TestMessagePanel extends JFrame {
>>>
>>> * * *public TestMessagePanel() {
>>> ...
>>> * * *}
>>>
>>> * * *public static void main(String[] args) {
>>> * * * * *TestMessagePanel frame = new TestMessagePanel();
>>> * * * * *frame.setSize(300, 200);
>>> * * * * *frame.setTitle("TestMessagePanel");
>>> * * * * *frame.setLocationRelativeTo(null);
>>> * * * * *frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOS E);
>>> * * * * *frame.setVisible(true);
>>>
>>> * * *}//end main()
>>>
>>> }
>>> ...
>
>> The problem with this code is that it teaches the bad and bug-prone
>> practice of creating GUI elements on the main thread instead of the
>> EDT. *Don't use this book. *The author apparently didn't know what he
>> was doing.
>> ...
>> But you should never, never, never do GUI magic off the EDT!
>
> Maybe the book is just not new.
>
> It was common practice to initiate the Swing form from the
> main thread for some years until people got aware of the
> potential issue.

That may be the excuse, but it doesn't improve the usefulness of the
book. He should still get a book that shows the correct idioms.

And it isn't a potential issue, it's an actual issue.

--
Lew

On Jul 23, 11:39*pm, Steve Sobol <sjso...@JustThe.net> wrote:
> In article <4e2b4456$0$306$14726...@news.sunsite.dk>, Arne Vajhøj
> says...
>
>
>
> > On 7/23/2011 1:41 PM, blm...@myrealbox.com wrote:
> > >> It's also bad practice to use import-on-demand (import '*') rather
> > >> than single-type imports.
>
> > > In code meant for compiling and execution, agreed. *In code meant
> > > for display in dead-tree documentation, though .... *
>
> > Having specific imports makes it easier to see where the classes
> > come from.
>
> > I would tend to say that is even more important for dead tree docs
> > than for code.
>
> I agree. And I can't speak for other IDE's [sic], but in Eclipse, updating
> your list of specific imports can be done by hitting Ctrl-Shift-O.
> ("Organize Imports")
>
> Takes a fraction of a second

I believe it's Ctrl-Shift-I for the exact same feature in NetBeans.
No doubt IntelliJ and others have the same feature.

--
Lew

On Jul 26, 2:15*am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Gene Wirchenko <ge...@ocis.net> writes:
> >>I would not call an »interesting idea«, what is the
> >>common standard of object-oriented programming teaching.
> >>Obviously, Getters and Setters break encapsulation.
> >Getters: yes. *Setters: maybe.
> >What is wrong with something like:
> >FilePrinter r=new FilePrinter();
> >// General Options
> >r.SetPrinter("\\Boojum");
> >r.SetCopies(1);
> >r.SetDoubleSided(true);
>
> * Before I can answer this, I need to know, whether there are
> * setters in the code above. How do you define »setter«? Is a
> * »setter« any one-argument method, whose name begins with »Set«?
>
> * (To apply my own definition, I would need to see the
> * documentation of a method, to judge whether it is a »setter«.)

If one were following the Java naming conventions, it would be a
method whose name begins with "set".

--
Lew

On Jul 26, 2:19*am, Jukka Lahtinen <jtfjd...@hotmail.com.invalid>
wrote:
> lewbloch <lewbl...@gmail.com> writes:
> > Chad wrote:
> >> The following code, which is taken from one of my school books,
> > Really, don't use this book. *Get a good book.
>
> I don't argue about that, but..
> TOP told us it's a school book. When at school, were you allowed to
> choose the books yourself?

Yes, as long as I also chose the books the teacher specified.

I had Calculus III with a book that mixed up the "u", "v" and "w"
variables in the examples. I spent many a sleepless night puzzling
whether the book was wrong or I was. At least three-quarters of the
time it was the book.

If you are committed to learning and the book is bad, you get a good
book and learn it independently of whatever the professor mandates.
If you're only committed to doing the minimum and winding up knowing
nothing, you use the bad book.

> OTOH, it would probably be a good idea to point the faults out to the
> teacher.

And to get a good book.

--
Lew

On 26 Jul 2011 09:15:51 GMT, (Stefan Ram)
wrote:

>Gene Wirchenko <> writes:
>>>I would not call an »interesting idea«, what is the
>>>common standard of object-oriented programming teaching.
>>>Obviously, Getters and Setters break encapsulation.
>>Getters: yes. Setters: maybe.
>>What is wrong with something like:
>>FilePrinter r=new FilePrinter();
>>// General Options
>>r.SetPrinter("\\Boojum");
>>r.SetCopies(1);
>>r.SetDoubleSided(true);
>
> Before I can answer this, I need to know, whether there are
> setters in the code above. How do you define »setter«? Is a
> »setter« any one-argument method, whose name begins with »Set«?

In my example, yes. In general, no.

> (To apply my own definition, I would need to see the
> documentation of a method, to judge whether it is a »setter«.)

Are you going by whether the setter uncritically sets the value
or whether it checks the value? To me, the former is bad, but the
latter is fine.

Sincerely,

Gene Wirchenko

Gene Wirchenko <> writes:
>>>What is wrong with something like:
>>>FilePrinter r=new FilePrinter();
>>>// General Options
>>>r.SetPrinter("\\Boojum");
>>>r.SetCopies(1);
>>>r.SetDoubleSided(true);
>>Before I can answer this, I need to know, whether there are
>>setters in the code above. How do you define »setter«? Is a
>>»setter« any one-argument method, whose name begins with »Set«?
>In my example, yes. In general, no.

There is nothing wrong with one-argument methods whose
name begins with »Set« (except that common Java naming
style is to use lower-case method names).

>>(To apply my own definition, I would need to see the
>>documentation of a method, to judge whether it is a »setter«.)
>Are you going by whether the setter uncritically sets the value
>or whether it checks the value?

According to

http://c2.com/cgi/wiki?AccessorsAreEvil

»accessors are methods that let you read and write the
value of an instance variable of an object«.

My personal definition is similar:

»An accessor is any method whose contract contains a
reference to an instance variable.«

Since I do not know whether your methods set the value of an
instance variable, I do not know, whether they are »setters«
in the sense of my definition. I would need to be able to
read their contract (documentation) to learn about this.

When their contract (documentation) does not contain such
references, encapsulation is not broken.

On 26 Jul 2011 18:20:41 GMT, (Stefan Ram)
wrote:

>Gene Wirchenko <> writes:
>>>>What is wrong with something like:
>>>>FilePrinter r=new FilePrinter();
>>>>// General Options
>>>>r.SetPrinter("\\Boojum");
>>>>r.SetCopies(1);
>>>>r.SetDoubleSided(true);
>>>Before I can answer this, I need to know, whether there are
>>>setters in the code above. How do you define »setter«? Is a
>>>»setter« any one-argument method, whose name begins with »Set«?
>>In my example, yes. In general, no.
>
> There is nothing wrong with one-argument methods whose
> name begins with »Set« (except that common Java naming
> style is to use lower-case method names).
>
>>>(To apply my own definition, I would need to see the
>>>documentation of a method, to judge whether it is a »setter«.)
>>Are you going by whether the setter uncritically sets the value
>>or whether it checks the value?
>
> According to
>
>http://c2.com/cgi/wiki?AccessorsAreEvil
>
> »accessors are methods that let you read and write the
> value of an instance variable of an object«.
>
> My personal definition is similar:
>
> »An accessor is any method whose contract contains a
> reference to an instance variable.«

Then, the answer is no. However, the contract for such a method
of mine would have reference to the concept that the instance variable
embodies. I might write the contract for .SetCopies() as:

.SetCopies() takes one parameter, an integer which is the number
of copies of the file to be printed that will be made when .Print() is
called (assuming sufficient valid printing parameters have been set).
The number of copies must be non-negative.

If I am reading you correctly, for the above, the answer is no,
but if I change the contract to refer to the instance variable, say
..NumCopies, then it would be a setter. This distinction strikes me as
rather less than useful. "So, is it a setter?" "I can not tell. I
have not read the contract."

> Since I do not know whether your methods set the value of an
> instance variable, I do not know, whether they are »setters«
> in the sense of my definition. I would need to be able to
> read their contract (documentation) to learn about this.

Read my example contract above. It does not mention an instance
variable, but any reasonable implementation that I am likely to do
would use one.

> When their contract (documentation) does not contain such
> references, encapsulation is not broken.

They set something. Whether it is an instance variable or not is
irrelevant to their use.

Sincerely,

Gene Wirchenko

Gene Wirchenko <> writes:
>>Since I do not know whether your methods

(insert »according to their contract«, here)

>> set the value of an
>>instance variable, I do not know, whether they are »setters«
>>in the sense of my definition. I would need to be able to
>>read their contract (documentation) to learn about this.
>Read my example contract above. It does not mention an instance
>variable, but any reasonable implementation that I am likely to do
>would use one.

Ok, then - to me - it is not a »setter«.

>They set something. Whether it is an instance variable or not is
>irrelevant to their use.

That is even another reason not to make references to instance
variables in the contract of a method.

A »Setter« to me is a method with a contract like:

»... sets the private field "alpha" to the argument value.«

Your method does not set a »field« but a »property« of the object.
Its contract does not allow a party to deduce with
certainity something about the private fields of the object.
Therefore, it does not break encapsulation.

Gene Wirchenko <> writes:
>Read my example contract above. It does not mention an instance
>variable, but any reasonable implementation that I am likely to do
>would use one.

A reasonable implementation might be:

public void SetCopies( final int number )
{ this.printerDelegate.setCopies( number ); }

, i.e., one which does not modify an instance variable, or

public void SetCopies( final int number )
{ this.getPrinterDelegate().setCopies( number ); }

, i.e., one which does not use any instance variable.

Patricia Shanahan <> writes:
>1. A method whose contract specifies setting an instance variable.
>2. A method whose contract specifies setting a logical property of the
>object.
>To me, it seems wasteful to use an nice, short, simple term for
>something that should *never* exist, when it could equally well be used
>for something that is actually useful, so I prefer the second definition.

I now try to look it up in the »Wikipedia.« The first relevant content
I find with my search approach is:

»Unlike the "getter" and "setter" methods of other
languages like C++ or Java, accessor methods in Ruby are
created with a single line of code via metaprogramming.«

http://en.wikipedia.org/wiki/Ruby_(programming_language)

This seems to imply the meaning »1.«.

The next hit:

»Integer extend [
asClosure [
| value |
value := self.
^{ [ | value := x ]. [ value ] }
]
]

blocks := 10 asClosure.
setter := blocks first.
getter := blocks second.
getter value "=> 10"
setter value: 21 "=> 21"
getter value "=> 21"«

http://en.wikipedia.org/wiki/GNU_Smalltalk

This also seems to imply an access to the internal
variable »value« of the closure. Disclaimer: I did
not learn Smalltalk yet.

Found Last, but not appreciated least, the main article:

»The mutator method, sometimes called a "setter", is
most often used in object-oriented programming, in
keeping with the principle of encapsulation. According
to this principle, member variables of a class are made
private to hide and protect them from other code, and
can only be modified by a public member function (the
mutator method), which takes the desired new value as a
parameter, optionally validates it, and modifies the
private member variable.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Often a "setter" is accompanied by a "getter" (also
known as an accessor), which returns the value of the
private member variable.«
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
http://en.wikipedia.org/wiki/Mutator_method

Reads like more close to »1.« to me.

(The foregoing quotations from the »Wikipedia« that I have
provided in this Usenet post were not written into the
»Wikipedia« by me. I never edited any of the »Wikipedia«
articles quoted above, I just underlined two lines in this
Usenet post.)