Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24417 > unrolled thread

About java program.

Back to article view | Back to comp.lang.java.programmer

Contents

  About java program. rajbhaumik@gmail.com - 2013-06-15 13:38 -0700
    Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-06-15 16:50 -0400
    Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-16 01:12 +0200
      Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-16 14:21 +0100
        Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-16 17:28 +0200
          Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-16 19:52 +0100
            Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-06-16 15:50 -0400
          Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 09:36 +0100
          Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 09:49 -0300
            Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 14:46 +0100
              Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 13:32 -0300
              Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-17 20:32 +0200
                Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-17 14:49 -0400
                  Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 18:38 -0300
                    Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-17 18:30 -0400
                      Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 17:33 -0300
                    Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:56 -0400
                  Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-18 00:13 +0200
                    Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 17:50 -0300
                      Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:50 +0100
                        Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-19 15:16 -0300
                          Re: About java program. Lew <lewbloch@gmail.com> - 2013-06-19 16:20 -0700
                            Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 13:31 -0400
                              Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 18:16 -0400
                              Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 19:21 -0400
                                Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:07 -0400
                                  Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:21 -0400
                                    Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:40 -0400
                                  Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 22:20 -0400
                                    Re: About java program. Lew <lewbloch@gmail.com> - 2013-07-07 21:47 -0700
                                      Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 06:58 -0400
                                        Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 08:07 -0400
                                          Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 08:58 -0400
                                            Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 09:18 -0400
                                              Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 09:47 -0400
                                                Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 10:07 -0400
                      Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-19 16:42 +0200
                        Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-20 23:33 -0300
                          Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 04:16 +0000
                            Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-21 12:27 +0200
                              Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 21:14 +0000
                                Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-21 23:37 +0200
                                  Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 23:42 +0000
                                Re: About java program. Gene Wirchenko <genew@telus.net> - 2013-06-24 13:00 -0700
                                  Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-24 21:29 +0000
                                    Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-24 21:42 +0000
                            Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-21 23:59 -0300
                              Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-22 13:30 +0000
                          Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-21 16:24 +0200
                            Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-21 22:39 -0300
                              Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-22 19:25 +0200
                                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 19:41 +0100
                                  Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-23 03:53 +0200
                                    Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-23 09:21 +0100
                                      Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-24 18:57 +0200
                                        Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-24 18:14 +0100
                            Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 09:03 +0100
                              Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-22 19:26 +0200
                                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 18:51 +0100
                      Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:58 -0400
                  Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-19 00:38 +0200
                    Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-18 18:56 -0400
                      Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 21:26 -0300
                        Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-19 21:20 +0200
                          Re: About java program. Sven Köhler <remove-sven.koehler@gmail.com> - 2013-06-20 11:23 +0300
                            Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-20 19:18 +0200
                              Re: About java program. blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-07-15 20:20 +0000
                      Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 09:14 +0100
                    Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 09:11 +0100
                      Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 23:11 -0400
                        Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-05 09:13 +0100
                          Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-05 23:15 +0200
                            Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 22:03 -0400
                              Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-06 13:01 +0200
                                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 13:43 +0100
                                Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-06 14:17 +0000
                                Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-06 16:18 -0400
                                  Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 21:42 +0100
                            Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 09:16 +0100
                              Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-06 13:14 +0200
                                Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-06 08:22 -0400
                                  Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-07 20:43 +0200
                                    Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-07 18:07 -0400
                                      Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-07 19:35 -0400
                                        Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-07 20:42 -0400
                                      Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-08 20:50 +0200
                                        Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-08 15:01 -0400
                                          Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-08 23:29 +0200
                                Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-06 16:27 -0400
                                  Re: About java program. Lew <lewbloch@gmail.com> - 2013-07-06 13:41 -0700
                          Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:59 -0400
                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 21:06 +0100
              Re: About java program. Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-06-17 17:36 -0500
                Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-18 08:24 +0200
                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-18 09:03 +0100
                  Re: About java program. Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-06-18 13:07 -0500
                  Re: About java program. Lew <lewbloch@gmail.com> - 2013-06-18 14:48 -0700
                    Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:36 +0100
                Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 23:33 -0300
                  Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:34 +0100
              Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:53 -0400
    Re: About java program. Roedy Green <see_website@mindprod.com.invalid> - 2013-06-16 07:04 -0700
    Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-06-18 04:06 -0400

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#24417 — About java program.

import acm.program.*;
public class askYesNoQuestion extends ConsoleProgram {
	public void run(){
		String str=readLine("Would you like instructions");
		println(askYesNoquestion(str));
	}
7.	    private boolean askYesNoquestion (String str){
	    	if(str.equals("yes"))return true;
	    	if(str.equals("no")) return false;    	
	}

}
 the false is that , the program cannot be executed, because no 7 said , this method must return a type of boolean.

[toc] | [next] | [standalone]

#24418

On 6/15/2013 4:38 PM, rajbhaumik@gmail.com wrote:
> import acm.program.*;
> public class askYesNoQuestion extends ConsoleProgram {
> 	public void run(){
> 		String str=readLine("Would you like instructions");
> 		println(askYesNoquestion(str));
> 	}
> 7.	    private boolean askYesNoquestion (String str){
> 	    	if(str.equals("yes"))return true;
> 	    	if(str.equals("no")) return false;    	
> 	}
>
> }
>   the false is that , the program cannot be executed, because no 7 said , this method must return a type of boolean.

Let meask you a question: what value will the method return if
the input string is "xxx"?

Arne

[toc] | [prev] | [next] | [standalone]

#24421

On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
> import acm.program.*;
> public class askYesNoQuestion extends ConsoleProgram {
> 	public void run(){
> 		String str=readLine("Would you like instructions");
> 		println(askYesNoquestion(str));
> 	}
> 7.	    private boolean askYesNoquestion (String str){
> 	    	if(str.equals("yes"))return true;
> 	    	if(str.equals("no")) return false;    	
> 	}
>
> }
> the false is that , the program cannot be executed, because no 7
> said, this method must return a type of boolean.

And, do you have a particular question or are you just informing us of 
your compiler error?

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24423

On 16/06/13 00:12, Robert Klemme wrote:
> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>> import acm.program.*;
>> public class askYesNoQuestion extends ConsoleProgram {
>>     public void run(){
>>         String str=readLine("Would you like instructions");
>>         println(askYesNoquestion(str));
>>     }
>> 7.        private boolean askYesNoquestion (String str){
>>             if(str.equals("yes"))return true;
>>             if(str.equals("no")) return false;
>>     }
>>
>> }
>> the false is that , the program cannot be executed, because no 7
>> said, this method must return a type of boolean.
>

One possible solution (not compiled or tested)

private boolean askYesNoquestion (String str){
    boolean response = false;
    if(str.equals("yes")){
        response = true;
    }
    return response;
}

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24425

On 16.06.2013 15:21, lipska the kat wrote:
> On 16/06/13 00:12, Robert Klemme wrote:
>> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>>> import acm.program.*;
>>> public class askYesNoQuestion extends ConsoleProgram {
>>>     public void run(){
>>>         String str=readLine("Would you like instructions");
>>>         println(askYesNoquestion(str));
>>>     }
>>> 7.        private boolean askYesNoquestion (String str){
>>>             if(str.equals("yes"))return true;
>>>             if(str.equals("no")) return false;
>>>     }
>>>
>>> }
>>> the false is that , the program cannot be executed, because no 7
>>> said, this method must return a type of boolean.
>>
>
> One possible solution (not compiled or tested)
>
> private boolean askYesNoquestion (String str){
>     boolean response = false;
>     if(str.equals("yes")){
>         response = true;
>     }
>     return response;
> }

Why are you making it so complicated?  Just do

private static boolean isStringYes(String str) {
    return str.equals("yes");
}

Or, for NPE safety:

private static boolean isStringYes(String str) {
    return "yes".equals(str);
}

Btw, I also changed the name because the method did not ask a question 
at all.

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24427

On 16/06/13 16:28, Robert Klemme wrote:
> On 16.06.2013 15:21, lipska the kat wrote:
>> On 16/06/13 00:12, Robert Klemme wrote:
>>> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>>>> import acm.program.*;
>>>> public class askYesNoQuestion extends ConsoleProgram {
>>>>     public void run(){
>>>>         String str=readLine("Would you like instructions");
>>>>         println(askYesNoquestion(str));
>>>>     }
>>>> 7.        private boolean askYesNoquestion (String str){
>>>>             if(str.equals("yes"))return true;
>>>>             if(str.equals("no")) return false;
>>>>     }
>>>>
>>>> }
>>>> the false is that , the program cannot be executed, because no 7
>>>> said, this method must return a type of boolean.
>>>
>>
>> One possible solution (not compiled or tested)
>>
>> private boolean askYesNoquestion (String str){
>>     boolean response = false;
>>     if(str.equals("yes")){
>>         response = true;
>>     }
>>     return response;
>> }
>
> Why are you making it so complicated?  Just do
>
> private static boolean isStringYes(String str) {
>     return str.equals("yes");
> }

This is the age old argument about the use and abuse of the return 
statement. I can't see us coming to a MAC so there's little point 
arguing about it here really.

But OK, it's another solution.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24429

On 6/16/2013 2:52 PM, lipska the kat wrote:
> On 16/06/13 16:28, Robert Klemme wrote:
>> On 16.06.2013 15:21, lipska the kat wrote:
>>> On 16/06/13 00:12, Robert Klemme wrote:
>>>> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>>>>> import acm.program.*;
>>>>> public class askYesNoQuestion extends ConsoleProgram {
>>>>>     public void run(){
>>>>>         String str=readLine("Would you like instructions");
>>>>>         println(askYesNoquestion(str));
>>>>>     }
>>>>> 7.        private boolean askYesNoquestion (String str){
>>>>>             if(str.equals("yes"))return true;
>>>>>             if(str.equals("no")) return false;
>>>>>     }
>>>>>
>>>>> }
>>>>> the false is that , the program cannot be executed, because no 7
>>>>> said, this method must return a type of boolean.
>>>>
>>>
>>> One possible solution (not compiled or tested)
>>>
>>> private boolean askYesNoquestion (String str){
>>>     boolean response = false;
>>>     if(str.equals("yes")){
>>>         response = true;
>>>     }
>>>     return response;
>>> }
>>
>> Why are you making it so complicated?  Just do
>>
>> private static boolean isStringYes(String str) {
>>     return str.equals("yes");
>> }
>
> This is the age old argument about the use and abuse of the return
> statement. I can't see us coming to a MAC so there's little point
> arguing about it here really.
>
> But OK, it's another solution.

How can it be misuse of return to have a non-void method
with a single return statement as the last statement returning
what should be returned?

Arne

[toc] | [prev] | [next] | [standalone]

#24433

On 16/06/13 16:28, Robert Klemme wrote:
> On 16.06.2013 15:21, lipska the kat wrote:
>> On 16/06/13 00:12, Robert Klemme wrote:
>>> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>>>> import acm.program.*;
>>>> public class askYesNoQuestion extends ConsoleProgram {
>>>>     public void run(){
>>>>         String str=readLine("Would you like instructions");
>>>>         println(askYesNoquestion(str));
>>>>     }
>>>> 7.        private boolean askYesNoquestion (String str){
>>>>             if(str.equals("yes"))return true;
>>>>             if(str.equals("no")) return false;
>>>>     }
>>>>
>>>> }
>>>> the false is that , the program cannot be executed, because no 7
>>>> said, this method must return a type of boolean.
>>>
>>
>> One possible solution (not compiled or tested)
>>
>> private boolean askYesNoquestion (String str){
>>     boolean response = false;
>>     if(str.equals("yes")){
>>         response = true;
>>     }
>>     return response;
>> }
>
> Why are you making it so complicated?  Just do

Complicated?

What's complicated about it.
I thought it was eminently understandable.

Do you need me to explain it to you? ;-)

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24435

On 06/16/2013 12:28 PM, Robert Klemme wrote:
> On 16.06.2013 15:21, lipska the kat wrote:
>> On 16/06/13 00:12, Robert Klemme wrote:
>>> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>>>> import acm.program.*;
>>>> public class askYesNoQuestion extends ConsoleProgram {
>>>>     public void run(){
>>>>         String str=readLine("Would you like instructions");
>>>>         println(askYesNoquestion(str));
>>>>     }
>>>> 7.        private boolean askYesNoquestion (String str){
>>>>             if(str.equals("yes"))return true;
>>>>             if(str.equals("no")) return false;
>>>>     }
>>>>
>>>> }
>>>> the false is that , the program cannot be executed, because no 7
>>>> said, this method must return a type of boolean.
>>>
>>
>> One possible solution (not compiled or tested)
>>
>> private boolean askYesNoquestion (String str){
>>     boolean response = false;
>>     if(str.equals("yes")){
>>         response = true;
>>     }
>>     return response;
>> }
>
> Why are you making it so complicated?  Just do
>
> private static boolean isStringYes(String str) {
>     return str.equals("yes");
> }
>
> Or, for NPE safety:
>
> private static boolean isStringYes(String str) {
>     return "yes".equals(str);
> }
>
> Btw, I also changed the name because the method did not ask a question
> at all.
>
> Cheers
>
>      robert
>
>
To some extent I agree with you, Robert.

A little side note about the NPE-safe form of doing "equals": this can 
sometimes bite because of the very liberal method signature. Just last 
week I was doing some CXF+JAXB work with SOAP, and for a few hours I was 
perplexed as to why a a path was not being taken. Anyone who has worked 
with generated code for SOAP knows how verbose and encapsulated and 
boilerplate it is; lots of commenting and good white space needed, and 
copy & paste is to be avoided (albeit tempting).

Anyway, come to find out that I was doing a String equals (had to be 
equals, not equalsIgnoreCase), and the argument was not a String but 
through a typo an MXString. equals() of course happily accepted that and 
always returned false.

That's not to say it wasn't my mistake, it was. But I've found that 
equals() is a relatively fertile source of program defects.

With your method it's not a concern, you're controlling the type of the 
parameter. But in wider expanses of code then it's important to nail 
down that the 2 objects being compared are of the expected types. Code 
reviews, maybe even an instanceof if correctness at this point is 
essential (more so than we usually desire but often don't achieve :-))

For String in particular, I wouldn't actually mind if there was an 
equals(String). In some cases I'll use String#compareTo(String) to 
achieve that.

To the original point, I agree to an extent. But the actual idiom that 
lipska used is not bad in general, if you're used to single return. It's 
sort of like *always* providing braces for conditionals, even for one 
liners, defensive coding in part, but also adhering to personal coding 
style.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24436

On 17/06/13 13:49, Arved Sandstrom wrote:
> On 06/16/2013 12:28 PM, Robert Klemme wrote:
>> On 16.06.2013 15:21, lipska the kat wrote:
>>> On 16/06/13 00:12, Robert Klemme wrote:
>>>> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>>>>> import acm.program.*;
>>>>> public class askYesNoQuestion extends ConsoleProgram {
>>>>>     public void run(){
>>>>>         String str=readLine("Would you like instructions");
>>>>>         println(askYesNoquestion(str));
>>>>>     }
>>>>> 7.        private boolean askYesNoquestion (String str){
>>>>>             if(str.equals("yes"))return true;
>>>>>             if(str.equals("no")) return false;
>>>>>     }
>>>>>
>>>>> }
>>>>> the false is that , the program cannot be executed, because no 7
>>>>> said, this method must return a type of boolean.
>>>>
>>>
>>> One possible solution (not compiled or tested)
>>>
>>> private boolean askYesNoquestion (String str){
>>>     boolean response = false;
>>>     if(str.equals("yes")){
>>>         response = true;
>>>     }
>>>     return response;
>>> }

[snip]

> To the original point, I agree to an extent. But the actual idiom that
> lipska used is not bad in general, if you're used to single return. It's
> sort of like *always* providing braces for conditionals, even for one
> liners, defensive coding in part, but also adhering to personal coding
> style.

... and what is your opinion of defensive coding?

Anyone who has ever written software to interact with a user via a 
device interface knows (or should know) that defensive coding is de-riguer.

If you don't want the device to crash every time someone does something 
unexpected you need to anticipate no only the unexpected but the 
unanticipated. There is *no* room for error.

This discipline is hard to learn and once learned even harder to 
un-learn. This is why I don't like things like

return str.equals("yes");

It's lazy coding and harder to understand than my example and yes, I 
realize that it's only a one liner but the next stage in the 
'development' of this style is

if(something){
    return something;
}
else if(something else){
    return something else;
}
else{
    return some other value
}

It is much easier to understand and debug
the following

type var;

if(something){
    var = something;
}
else if(something else){
    var = something else;
}
else{
    var = some other value
}

return var;

If I was doing a proper job and not just providing a simple example I 
would have had a pre-condition on the method *and* exception handling 
*and* braces around every conditional, even one liners,
*and* a fallback position if the operation was mission critical. So yes, 
it's my personal style learned from painful experience.

Thank you for understanding

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24437

On 06/17/2013 10:46 AM, lipska the kat wrote:
> On 17/06/13 13:49, Arved Sandstrom wrote:
>> On 06/16/2013 12:28 PM, Robert Klemme wrote:
>>> On 16.06.2013 15:21, lipska the kat wrote:
>>>> On 16/06/13 00:12, Robert Klemme wrote:
>>>>> On 15.06.2013 22:38, rajbhaumik@gmail.com wrote:
>>>>>> import acm.program.*;
>>>>>> public class askYesNoQuestion extends ConsoleProgram {
>>>>>>     public void run(){
>>>>>>         String str=readLine("Would you like instructions");
>>>>>>         println(askYesNoquestion(str));
>>>>>>     }
>>>>>> 7.        private boolean askYesNoquestion (String str){
>>>>>>             if(str.equals("yes"))return true;
>>>>>>             if(str.equals("no")) return false;
>>>>>>     }
>>>>>>
>>>>>> }
>>>>>> the false is that , the program cannot be executed, because no 7
>>>>>> said, this method must return a type of boolean.
>>>>>
>>>>
>>>> One possible solution (not compiled or tested)
>>>>
>>>> private boolean askYesNoquestion (String str){
>>>>     boolean response = false;
>>>>     if(str.equals("yes")){
>>>>         response = true;
>>>>     }
>>>>     return response;
>>>> }
>
> [snip]
>
>> To the original point, I agree to an extent. But the actual idiom that
>> lipska used is not bad in general, if you're used to single return. It's
>> sort of like *always* providing braces for conditionals, even for one
>> liners, defensive coding in part, but also adhering to personal coding
>> style.
>
> ... and what is your opinion of defensive coding?

Not far different from yours, apparently.

> Anyone who has ever written software to interact with a user via a
> device interface knows (or should know) that defensive coding is de-riguer.
>
> If you don't want the device to crash every time someone does something
> unexpected you need to anticipate no only the unexpected but the
> unanticipated. There is *no* room for error.
>
> This discipline is hard to learn and once learned even harder to
> un-learn. This is why I don't like things like
>
> return str.equals("yes");
>
> It's lazy coding and harder to understand than my example and yes, I
> realize that it's only a one liner but the next stage in the
> 'development' of this style is
>
> if(something){
>     return something;
> }
> else if(something else){
>     return something else;
> }
> else{
>     return some other value
> }
>
> It is much easier to understand and debug
> the following
>
> type var;
>
> if(something){
>     var = something;
> }
> else if(something else){
>     var = something else;
> }
> else{
>     var = some other value
> }
>
> return var;
>
> If I was doing a proper job and not just providing a simple example I
> would have had a pre-condition on the method *and* exception handling
> *and* braces around every conditional, even one liners,
> *and* a fallback position if the operation was mission critical. So yes,
> it's my personal style learned from painful experience.
>
> Thank you for understanding
>
> lipska
>
Generally speaking all of this boils down to one thing: errors happen 
when the same developer - you, me, anyone - has white-box knowledge of, 
and maybe responsibility for, both called *and* calling code. This 
extends even to method lexical scope where a developer may write some 
stuff that makes assumptions about his or her own code in the same 
method 50 lines previous.

I daresay that this state of affairs is the norm. Sure, a whole bunch of 
developers work on NASA or defense or avionics or Big Healthcare type 
projects where you've got a great deal of imposed rigor. But very likely 
most developers own a whole bunch of code, and I'm sure that a large 
number of us write entire apps. For example, as a software consultant I 
often do analyze, design and code entire applications.

So, given this, it's necessary to be somewhat schizophrenic - when 
working on method X in class A, and it's called by method Y in class B 
and method Z in class C, and you are writing *all* of them, you need to 
wear 3 hats. And by extension N hats as you implement the entire app, 
and even more because you're also doing design and analysis.

God forbid that the developer also does the functional and integration 
and system testing, but this is not rare. But let's ignore that aspect 
of real life. :-)

If there actually is a good sized team the same considerations apply. 
The nature of the beast these days is that often developers have 
visibility into calling code that they don't have responsibility for, 
because they do git or svn or hg, and they inevitably see way more than 
they ought to.

I've rarely seen it done, because it adds substantial cost, but a better 
approach would be to have each developer assigned (a) method(s) in a 
class just write the class, and also be given time to write necessary 
scaffolding in the form of tests that exercises their code. They never 
see the complete codebase. The advantage of this is that they write to a 
written design spec and not to knowledge of other code, and that they 
have also necessarily written useful tests.

Robert's method, the NPE-safe one that also types the method parameter, 
is not objectionable to me precisely because the equals is encapsulated 
in a method that constrains the type. Trivial methods of this sort are 
quite handy as private methods and make the code more robust, since 
equals() by itself is too Wild West.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24439

On Mon, 17 Jun 2013 14:46:57 +0100, lipska the kat wrote:

> return str.equals("yes");

> It's lazy coding and harder to understand than my example and yes, I 
> realize that it's only a one liner but the next stage in the 
> 'development' of this style is

Personally, I found your example considerably harder to read than the one
liner, as well as harder to read than what would have been my solution:

private boolean askYesNoquestion (String str){
    if(str.equals("yes"))
        return true;

    return false;
}

Of course, YMMV. Obviously, I find code written the way I would write it
easier to read, so I can't be objective. The problem I have with this code:

> type var;

> if(something){
>     var = something;
> }

is that I can't tell what is returned if 'something' is true. Unless I look
at all the following code, var could easily be assigned a second time to
something different before it is returned.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#24440

On 6/17/2013 2:32 PM, Joerg Meier wrote:
>[...]
> Personally, I found your example considerably harder to read than the one
> liner, as well as harder to read than what would have been my solution:
>
> private boolean askYesNoquestion (String str){
>      if(str.equals("yes"))
>          return true;
>
>      return false;
> }

     Or, for even greater clarity:

	private boolean askYesNoquestion(String str) {
	    boolean yes;
	    boolean no;
	    if (str != null && str.equals("yes")) {
	        yes = true;
	        no = false;
	    } else if (str != null && str.equals("no")) {
	        no = true;
	        yes = false;
	    } else {
	        yes = no = false;
	    }
	    return (no != true && yes != false) == true;
	}

(If we put our minds to it, I bet we can turn the one-liner
into an entire class hierarchy with runtime-selected plug-in
provider implementations!)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24442

On 06/17/2013 03:49 PM, Eric Sosman wrote:
> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>> [...]
>> Personally, I found your example considerably harder to read than the one
>> liner, as well as harder to read than what would have been my solution:
>>
>> private boolean askYesNoquestion (String str){
>>      if(str.equals("yes"))
>>          return true;
>>
>>      return false;
>> }
>
>      Or, for even greater clarity:
>
>      private boolean askYesNoquestion(String str) {
>          boolean yes;
>          boolean no;
>          if (str != null && str.equals("yes")) {
>              yes = true;
>              no = false;
>          } else if (str != null && str.equals("no")) {
>              no = true;
>              yes = false;
>          } else {
>              yes = no = false;
>          }
>          return (no != true && yes != false) == true;
>      }
>
> (If we put our minds to it, I bet we can turn the one-liner
> into an entire class hierarchy with runtime-selected plug-in
> provider implementations!)
>
We can joke about it, but the one-liner has problems, especially if not 
wrapped in a method like Robert did. I've seen exactly that one-liner 
cause dozens of defects over the past 15 years of me doing Java. Not all 
programmers out there are superstars like all of us here in CLJP, in 
fact 99 percent aren't. If they - not graced with our wisdom and keen 
skills and perspicacity - decide to use that short form - they will 
almost *never* wrap it in a method that constrains the type being 
compared to, or does a null check if that's also unacceptable. In which 
case sooner or later - sooner usually - lack of controls elsewhere in 
the code, which is par for the course, will make that elegant little 
snippet fail.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24444

On 6/17/2013 5:38 PM, Arved Sandstrom wrote:
> On 06/17/2013 03:49 PM, Eric Sosman wrote:
>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>> [...]
>>> Personally, I found your example considerably harder to read than the
>>> one
>>> liner, as well as harder to read than what would have been my solution:
>>>
>>> private boolean askYesNoquestion (String str){
>>>      if(str.equals("yes"))
>>>          return true;
>>>
>>>      return false;
>>> }
>>
>>      Or, for even greater clarity:
>>
>>      private boolean askYesNoquestion(String str) {
>>          boolean yes;
>>          boolean no;
>>          if (str != null && str.equals("yes")) {
>>              yes = true;
>>              no = false;
>>          } else if (str != null && str.equals("no")) {
>>              no = true;
>>              yes = false;
>>          } else {
>>              yes = no = false;
>>          }
>>          return (no != true && yes != false) == true;
>>      }
>>
>> (If we put our minds to it, I bet we can turn the one-liner
>> into an entire class hierarchy with runtime-selected plug-in
>> provider implementations!)
>>
> We can joke about it, but the one-liner has problems, especially if not
> wrapped in a method like Robert did. I've seen exactly that one-liner
> cause dozens of defects over the past 15 years of me doing Java. Not all
> programmers out there are superstars like all of us here in CLJP, in
> fact 99 percent aren't. If they - not graced with our wisdom and keen
> skills and perspicacity - decide to use that short form - they will
> almost *never* wrap it in a method that constrains the type being
> compared to, or does a null check if that's also unacceptable. In which
> case sooner or later - sooner usually - lack of controls elsewhere in
> the code, which is par for the course, will make that elegant little
> snippet fail.

     "As simple as possible, no simpler."  The observation that
a simple construct can be misused -- a true observation -- does
not mean that the cure is to add complexity.  For one thing, the
added bulk offers more opportunities for misuse.

	static int sum(int a, int b) {
	    return a + b;
	}

	static int sum(int a, int b) {
	    int total = a;
	    total += b;
	    return total;
	}

	static int sum(int a, int b) {
	    assert Integer.MIN_VALUE <= a && a <= Integer.MAX_VALUE;
	    assert Integer.MAX_VALUE >= b && b >= Integer.MAX_VALUE;
	    Random rand = new Random();
	    int total;
	    do {
	        total = rand.nextInt();
	    } while (total - a != b);
	    return total;
	}

     Seriously, there are very few reasons to add complexity, and
many to reduce it.  Complexity can (sometimes) make a needed
performance improvement; complexity can (occasionally) provide a
self-check or a debugging hook; complexity can (almost never)
add clarity.

     (Truthfully, now: Did you spot the error above on first glance?)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24453

On 06/17/2013 07:30 PM, Eric Sosman wrote:
> On 6/17/2013 5:38 PM, Arved Sandstrom wrote:
>> On 06/17/2013 03:49 PM, Eric Sosman wrote:
>>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>>> [...]
>>>> Personally, I found your example considerably harder to read than the
>>>> one
>>>> liner, as well as harder to read than what would have been my solution:
>>>>
>>>> private boolean askYesNoquestion (String str){
>>>>      if(str.equals("yes"))
>>>>          return true;
>>>>
>>>>      return false;
>>>> }
>>>
>>>      Or, for even greater clarity:
>>>
>>>      private boolean askYesNoquestion(String str) {
>>>          boolean yes;
>>>          boolean no;
>>>          if (str != null && str.equals("yes")) {
>>>              yes = true;
>>>              no = false;
>>>          } else if (str != null && str.equals("no")) {
>>>              no = true;
>>>              yes = false;
>>>          } else {
>>>              yes = no = false;
>>>          }
>>>          return (no != true && yes != false) == true;
>>>      }
>>>
>>> (If we put our minds to it, I bet we can turn the one-liner
>>> into an entire class hierarchy with runtime-selected plug-in
>>> provider implementations!)
>>>
>> We can joke about it, but the one-liner has problems, especially if not
>> wrapped in a method like Robert did. I've seen exactly that one-liner
>> cause dozens of defects over the past 15 years of me doing Java. Not all
>> programmers out there are superstars like all of us here in CLJP, in
>> fact 99 percent aren't. If they - not graced with our wisdom and keen
>> skills and perspicacity - decide to use that short form - they will
>> almost *never* wrap it in a method that constrains the type being
>> compared to, or does a null check if that's also unacceptable. In which
>> case sooner or later - sooner usually - lack of controls elsewhere in
>> the code, which is par for the course, will make that elegant little
>> snippet fail.
>
>      "As simple as possible, no simpler."  The observation that
> a simple construct can be misused -- a true observation -- does
> not mean that the cure is to add complexity.  For one thing, the
> added bulk offers more opportunities for misuse.
>
>      static int sum(int a, int b) {
>          return a + b;
>      }
>
>      static int sum(int a, int b) {
>          int total = a;
>          total += b;
>          return total;
>      }
>
>      static int sum(int a, int b) {
>          assert Integer.MIN_VALUE <= a && a <= Integer.MAX_VALUE;
>          assert Integer.MAX_VALUE >= b && b >= Integer.MAX_VALUE;
>          Random rand = new Random();
>          int total;
>          do {
>              total = rand.nextInt();
>          } while (total - a != b);
>          return total;
>      }
>
>      Seriously, there are very few reasons to add complexity, and
> many to reduce it.  Complexity can (sometimes) make a needed
> performance improvement; complexity can (occasionally) provide a
> self-check or a debugging hook; complexity can (almost never)
> add clarity.
>
>      (Truthfully, now: Did you spot the error above on first glance?)
>
I didn't spot the error at first glance until you said there might be 
one and I went into code review mode. :-) Having said that, I'd shoot a 
coder who also perpetrated that while condition. :-)

Those asserts are actually an example of poorly maintainable code, and 
given the calibre of the average coder I'd rebuke the clever programmer 
who felt he had to write that. His follow-on maintainers may not get it 
completely.

Point being though, compactness is not always less complexity. It works 
in some languages, not in others. In APL-like languages like J it's an 
art form; in functional languages with powerful constructs it's often 
natural too. In languages like Java, it may or may not be appropriate, IMO.

I often decide against method chaining in Java, for example, so that I 
can break out the intermediate results and give them descriptive names. 
This is if the methods are my own or part of the app under development, 
I'm more willing to chain if the methods are part of a well-known and 
established API.

I also don't much do complicated logic tests. Not that yours are overly 
complex in your contrived example, but I wouldn't normally write that 
way. The fact that it takes some careful study to spot the error is a 
sign that maybe it's a maintenance problem waiting to happen.

That limits test is something that I might make a method actually. I do 
something similar if I need to do a zero-closeness test for floating 
points; I'll make that a carefully tested private utility method.

To recap, I don't think verbosity is always bad. I don't think that 
unrolling stuff and avoiding cleverness is bad. I am in vehement 
agreement with you that complexity almost never adds clarity; I dispute 
in a friendly fashion that careful extra code checks are the kind of 
complexity that is of concern. From a metrics standpoint, sure, there is 
some addition of complexity, but not of the type that concerns me.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24640

On 6/17/2013 5:38 PM, Arved Sandstrom wrote:
> On 06/17/2013 03:49 PM, Eric Sosman wrote:
>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>> [...]
>>> Personally, I found your example considerably harder to read than the
>>> one
>>> liner, as well as harder to read than what would have been my solution:
>>>
>>> private boolean askYesNoquestion (String str){
>>>      if(str.equals("yes"))
>>>          return true;
>>>
>>>      return false;
>>> }
>>
>>      Or, for even greater clarity:
>>
>>      private boolean askYesNoquestion(String str) {
>>          boolean yes;
>>          boolean no;
>>          if (str != null && str.equals("yes")) {
>>              yes = true;
>>              no = false;
>>          } else if (str != null && str.equals("no")) {
>>              no = true;
>>              yes = false;
>>          } else {
>>              yes = no = false;
>>          }
>>          return (no != true && yes != false) == true;
>>      }
>>
>> (If we put our minds to it, I bet we can turn the one-liner
>> into an entire class hierarchy with runtime-selected plug-in
>> provider implementations!)
>>
> We can joke about it, but the one-liner has problems, especially if not
> wrapped in a method like Robert did. I've seen exactly that one-liner
> cause dozens of defects over the past 15 years of me doing Java.

Really.

Could you give an example of a problem that would impact the
one liner, but not impact the four liner it replaced?

Arne

[toc] | [prev] | [next] | [standalone]

#24443

On 17/06/2013 20:49, Eric Sosman allegedly wrote:
> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>> [...]
>> Personally, I found your example considerably harder to read than the one
>> liner, as well as harder to read than what would have been my solution:
>>
>> private boolean askYesNoquestion (String str){
>>      if(str.equals("yes"))
>>          return true;
>>
>>      return false;
>> }
> 
>     Or, for even greater clarity:
> 
>     private boolean askYesNoquestion(String str) {
>         boolean yes;
>         boolean no;
>         if (str != null && str.equals("yes")) {
>             yes = true;
>             no = false;
>         } else if (str != null && str.equals("no")) {
>             no = true;
>             yes = false;
>         } else {
>             yes = no = false;
>         }
>         return (no != true && yes != false) == true;
>     }

Call me sceptical, but I'm sceptical: I find that one-line return
statement kinda confusing. For more clarity, it should be encapsulated:

public static boolean isTrue( boolean b ){
  boolean ret;
  if( b == true ){
    ret = true;
  }
  else {
    ret = false;
  }

  return ret;
}

private boolean askYesNoquestion(String str){
  ...
  return isTrue( ! isTrue(no) && isTrue(yes) );
}

Better, dontcha think?

;)

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#24454

On 06/17/2013 07:13 PM, Daniele Futtorovic wrote:
> On 17/06/2013 20:49, Eric Sosman allegedly wrote:
>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>> [...]
>>> Personally, I found your example considerably harder to read than the one
>>> liner, as well as harder to read than what would have been my solution:
>>>
>>> private boolean askYesNoquestion (String str){
>>>       if(str.equals("yes"))
>>>           return true;
>>>
>>>       return false;
>>> }
>>
>>      Or, for even greater clarity:
>>
>>      private boolean askYesNoquestion(String str) {
>>          boolean yes;
>>          boolean no;
>>          if (str != null && str.equals("yes")) {
>>              yes = true;
>>              no = false;
>>          } else if (str != null && str.equals("no")) {
>>              no = true;
>>              yes = false;
>>          } else {
>>              yes = no = false;
>>          }
>>          return (no != true && yes != false) == true;
>>      }
>
> Call me sceptical, but I'm sceptical: I find that one-line return
> statement kinda confusing. For more clarity, it should be encapsulated:
>
> public static boolean isTrue( boolean b ){
>    boolean ret;
>    if( b == true ){
>      ret = true;
>    }
>    else {
>      ret = false;
>    }
>
>    return ret;
> }
>
> private boolean askYesNoquestion(String str){
>    ...
>    return isTrue( ! isTrue(no) && isTrue(yes) );
> }
>
> Better, dontcha think?
>
> ;)
>
See my answer to Eric, all this is just ridiculing reasonable 
programming practices.

Even given Robert's example where the NPE-safe equals() is wrapped in a 
method that constrains the type of object being compared to, it may not 
be expected or acceptable that the String is null. So perhaps you do 
want to check for that, maybe with Apache StringUtils.isBlank().

Sure, the contrived absurd examples are retarded; so is the mockery of 
defensive programming. Oh well, there's a reason why most software 
projects still fail or go vastly over budget.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24466

On 18/06/13 21:50, Arved Sandstrom wrote:
> On 06/17/2013 07:13 PM, Daniele Futtorovic wrote:
>> On 17/06/2013 20:49, Eric Sosman allegedly wrote:
>>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>>> [...]
>>>> Personally, I found your example considerably harder to read than
>>>> the one
>>>> liner, as well as harder to read than what would have been my solution:
>>>>
>>>> private boolean askYesNoquestion (String str){
>>>>       if(str.equals("yes"))
>>>>           return true;
>>>>
>>>>       return false;
>>>> }
>>>
>>>      Or, for even greater clarity:

[snip drivel]

> See my answer to Eric, all this is just ridiculing reasonable
> programming practices.
>
> Even given Robert's example where the NPE-safe equals() is wrapped in a
> method that constrains the type of object being compared to, it may not
> be expected or acceptable that the String is null. So perhaps you do
> want to check for that, maybe with Apache StringUtils.isBlank().
>
> Sure, the contrived absurd examples are retarded; so is the mockery of
> defensive programming. Oh well, there's a reason why most software
> projects still fail or go vastly over budget.

Have you taken a 'sensible pill' by any chance?

I find myself agreeing with you twice in the same thread ... is it me?

IME one of the main reasons for failure is the attitude of certain team 
members that they are far too clever or far too important to the project 
to code responsibly. Their attitude is 'gosh, look  at me I'm so clever 
that I can write code that only I can understand'

I once knew a PhD who's attitude to commenting code was 'I don't need 
comments, I can read code'. Unfortunately this attitude carried over to 
his own code which was almost completely uncommented. When asked to 
comment his code his response was 'if you need comments then perhaps 
you'd better find something else to do' I fired his ass :-)

I think maybe a few of the responders to this thread could do with a 
lesson in basic code readability. Of course they would never admit it, 
they're obviously *way* to smart.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web