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

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

Interface with implied Constructor

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

Contents

  Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-09 18:41 +0800
    Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-09 04:08 -0700
      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 06:46 +0800
        Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-09 21:08 -0400
        Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-11 19:11 -0700
          Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-14 17:53 +0200
            Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-15 08:58 -0700
              Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-15 10:57 -0700
                [OT] Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-15 14:13 -0400
                  Re: [OT] Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-15 12:58 -0700
              Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-15 20:45 +0200
        Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-14 18:03 +0200
          Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-18 23:21 -0300
            Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-19 12:38 -0700
              Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 17:56 -0300
                Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-22 12:39 -0700
                  Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-22 16:02 -0400
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-22 18:08 -0300
                    Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-23 14:32 -0700
                      Re: Interface with implied Constructor Jim Gibson <jimsgibson@gmail.com> - 2013-07-23 14:43 -0700
                        Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-24 13:27 -0700
                          Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-24 18:20 -0300
                            Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-26 00:03 +0200
                          Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-24 21:18 +0000
                            Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-24 17:42 -0400
                      Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-23 18:19 -0400
                        Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-24 13:31 -0700
                      Re: Interface with implied Constructor Steven Simpson <ss@domain.invalid> - 2013-07-27 04:06 +0100
              Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-19 21:21 +0000
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 18:56 -0300
                  Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-19 18:10 -0400
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 20:46 -0300
                      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-20 12:42 +0800
                        Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-20 09:08 -0300
                        Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 09:08 -0400
                Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-19 19:20 -0700
                  Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-19 20:11 -0700
                    Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-20 12:26 +0800
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-20 09:38 -0300
                Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 19:46 +0200
                  Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-20 19:12 +0000
                    Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 17:12 -0400
                      Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-20 21:18 +0000
                        Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-21 12:13 +0200
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 16:18 -0300
                      Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-21 13:45 -0700
                      Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-21 16:58 -0400
                        Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 21:19 -0300
            Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 20:09 +0200
              Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 20:21 +0200
              Re: Interface with implied Constructor Joerg Meier <joergmmeier@arcor.de> - 2013-07-20 23:17 +0200
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 17:32 -0400
                  Re: Interface with implied Constructor Joerg Meier <joergmmeier@arcor.de> - 2013-07-21 00:10 +0200
              Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 17:53 -0300
    Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-09 18:13 -0700
      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 18:03 +0800
        Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-10 08:41 -0700
          Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-11 06:53 +0800
    Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-09 21:41 -0700
      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 17:55 +0800
      Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-10 14:52 -0700
    Re: Interface with implied Constructor Roedy Green <see_website@mindprod.com.invalid> - 2013-07-10 16:02 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#24780

On Sat, 20 Jul 2013 19:46:16 +0200, Robert Klemme wrote:

> On 19.07.2013 23:21, Martin Gregorie wrote:
>> On Fri, 19 Jul 2013 12:38:19 -0700, Gene Wirchenko wrote:
> 
>>>> I seriously dislike init() methods, not just in Java. Particularly if
> 
> Just for the record: I am also not very fond of init methods.  But I
> don't condemn them either.  It's not too unusual to require specific
> order of method invocations in an interface.  For example you need to
> have invoked java.util.List.add() once before List.get(0) can return
> anything meaningful.
> 
>>>> there is no sensible un-init()'ed object for the class. I just don't
>>>> see any credible argument for them. Like Richard said, actually:
>>>> "half-baked".
>>>>
>> I take the opposite approach to Robert over that for one reason: that
>> the only way to report init errors in a constructor is to throw an
>> Exception,
>> which means the instance declaration often needs to go inside a
>> try/catch block which can screw up scoping.
> 
> In what ways does this screw up scoping?
>
Just that I often find that I need access to the instance outside the try/
catch block containing the constructor call and I don't much like 
initialising the pointer as null.
  
>> If init errors are possible and must be caught, I prefer to use a
>> constructor that can't do anything that needs an Exception to be thrown
>> and finish the job with an init() method that can go in the following
>> try/catch block along with (some of) the other method calls.
> 
>  From your description I am not sure I understood the pattern you are
> advertising here.  Can you show this in code?  The thing which irritates
> me is that you want to have a "following try/catch" block.  What for?
>
This is a result of my dislike of using Exceptions to signal anything 
except a fatal error and may well be a hangover from writing a lot of C 
in the past. A method that returns reference to a library class whose 
constructor can throw an exception, e.g. Integer, but does not itself 
return an exception requires this sort of structure:

public class Altitude
{
  int    alt   = 0;
  String error = null;

  /**
   * Returning a negative number indicates an invalid height.
   */
  public int getHeight(String height)
  {
    Integer h = null;
    try 
    { 
      h = new Integer(height); 
      if (h < 0)
        error = "Below MSL"; 
    }
    catch (NumberFormatException e) 
    { 
      error = e.getMessage(); 
      h = new Integer(-1); 
    }
      
    return alt = h.intValue();  
  }

  public boolean isValid()
  { return error === null; }

  public String getError()
  { return error; }
}

This isn't a really good example because Integer provides other ways of 
doing the job, but it does illustrate the sort of scoping problem I'm 
talking about: that of allowing access to the Integer instance in both 
parts of the try/catch block as well as from surrounding parts of the 
method body.
 
In general I tend avoid the problem by structuring my classes so the 
constructor doesn't throw exceptions, often by passing arguments that may 
trigger recoverable errors as arguments to the method that uses them, 
e.g. passing a file name to an 'open' method rather than consuming it in 
the constructor.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#24782

On 7/20/2013 3:12 PM, Martin Gregorie wrote:
> On Sat, 20 Jul 2013 19:46:16 +0200, Robert Klemme wrote:
>
>> On 19.07.2013 23:21, Martin Gregorie wrote:
>>> [...]
>>> I take the opposite approach to Robert over that for one reason: that
>>> the only way to report init errors in a constructor is to throw an
>>> Exception,
>>> which means the instance declaration often needs to go inside a
>>> try/catch block which can screw up scoping.
>>
>> In what ways does this screw up scoping?
>>
> Just that I often find that I need access to the instance outside the try/
> catch block containing the constructor call and I don't much like
> initialising the pointer as null.

     Then ... don't initialize it.

	Thing thing;
	try {
	    thing = new Thing();
	} catch (DooWopDooWopDooWopException ex) {
	    logger.log(Level.SEVERE, "Eek!", ex);
	    throw ex;
	}
	System.out.println(thing.getSwing());
	...

This form has the advantage that the compiler will complain if
the all-important `throw ex;' is forgotten, whereas initializing
to null would just get you an NPE.

     Very occasionally there's a situation where you really do need
to use the null-ness of `thing' as an indication that construction
failed.  In that case, I'd still suggest not initializing:

	Thing thing;
	try {
	    thing = new Thing();
	} catch (DooWopDooWopDooWopException ex) {
	    logger.log(Level.SEVERE, "Eek!", ex);
	    thing = null;
	}
	if (thing != null) {
	    System.out.println(thing.getSwing());
	else {
	    System.out.println("It don't mean a thing");
	}

IMHO, situations like this are suggestive of a poorly-designed
Thing class (which you may be forced to endure), or of a method
that's trying to do too many things and might better be split up.

> This is a result of my dislike of using Exceptions to signal anything
> except a fatal error and may well be a hangover from writing a lot of C
> in the past. A method that returns reference to a library class whose
> constructor can throw an exception, e.g. Integer, but does not itself
> return an exception requires this sort of structure:
>
> public class Altitude
> {
>    int    alt   = 0;
>    String error = null;
>
>    /**
>     * Returning a negative number indicates an invalid height.
>     */
>    public int getHeight(String height)
>    {
>      Integer h = null;

     Since this initialization is useless (the variable will
always be overwritten, exception or no), why even have it?

>      try
>      {
>        h = new Integer(height);
>        if (h < 0)
>          error = "Below MSL";
>      }
>      catch (NumberFormatException e)
>      {
>        error = e.getMessage();
>        h = new Integer(-1);
>      }
>
>      return alt = h.intValue();
>    }
>
>    public boolean isValid()
>    { return error === null; }
>
>    public String getError()
>    { return error; }
> }
>
> This isn't a really good example because Integer provides other ways of
> doing the job, but it does illustrate the sort of scoping problem I'm
> talking about: that of allowing access to the Integer instance in both
> parts of the try/catch block as well as from surrounding parts of the
> method body.

     I don't see how the NumberFormatException has much to do
with it: Your getHeight() method needs the `h' at the point
of its return, so its scope must include the return statement.
The only "scoping issue" I can see is that the try block and the
catch block have their own subsidiary scopes in which `h' also
needs to be (and is) visible -- but then, why aren't you worried
about the scope of `height'?  (Or even of `error' and `alt'?)

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

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

#24785

On Sat, 20 Jul 2013 17:12:47 -0400, Eric Sosman wrote:

> On 7/20/2013 3:12 PM, Martin Gregorie wrote:
>> On Sat, 20 Jul 2013 19:46:16 +0200, Robert Klemme wrote:
>>
>>> On 19.07.2013 23:21, Martin Gregorie wrote:
>>>> [...]
>>>> I take the opposite approach to Robert over that for one reason: that
>>>> the only way to report init errors in a constructor is to throw an
>>>> Exception,
>>>> which means the instance declaration often needs to go inside a
>>>> try/catch block which can screw up scoping.
>>>
>>> In what ways does this screw up scoping?
>>>
>> Just that I often find that I need access to the instance outside the
>> try/
>> catch block containing the constructor call and I don't much like
>> initialising the pointer as null.
> 
>      Then ... don't initialize it.
> 
> 	Thing thing;
> 	try {
> 	    thing = new Thing();
> 	} catch (DooWopDooWopDooWopException ex) {
> 	    logger.log(Level.SEVERE, "Eek!", ex);
> 	    throw ex;
> 	}
> 	System.out.println(thing.getSwing());
> 	...
> 
> This form has the advantage that the compiler will complain if the
> all-important `throw ex;' is forgotten, whereas initializing to null
> would just get you an NPE.
> 
>      Very occasionally there's a situation where you really do need
> to use the null-ness of `thing' as an indication that construction
> failed.  In that case, I'd still suggest not initializing:
> 
> 	Thing thing;
> 	try {
> 	    thing = new Thing();
> 	} catch (DooWopDooWopDooWopException ex) {
> 	    logger.log(Level.SEVERE, "Eek!", ex);
> 	    thing = null;
> 	}
> 	if (thing != null) {
> 	    System.out.println(thing.getSwing());
> 	else {
> 	    System.out.println("It don't mean a thing");
> 	}
> 
> IMHO, situations like this are suggestive of a poorly-designed Thing
> class (which you may be forced to endure), or of a method that's trying
> to do too many things and might better be split up.
> 
>> This is a result of my dislike of using Exceptions to signal anything
>> except a fatal error and may well be a hangover from writing a lot of C
>> in the past. A method that returns reference to a library class whose
>> constructor can throw an exception, e.g. Integer, but does not itself
>> return an exception requires this sort of structure:
>>
>> public class Altitude {
>>    int    alt   = 0;
>>    String error = null;
>>
>>    /**
>>     * Returning a negative number indicates an invalid height.
>>     */
>>    public int getHeight(String height)
>>    {
>>      Integer h = null;
> 
>      Since this initialization is useless (the variable will
> always be overwritten, exception or no), why even have it?
> 
>>      try {
>>        h = new Integer(height);
>>        if (h < 0)
>>          error = "Below MSL";
>>      }
>>      catch (NumberFormatException e)
>>      {
>>        error = e.getMessage(); h = new Integer(-1);
>>      }
>>
>>      return alt = h.intValue();
>>    }
>>
>>    public boolean isValid()
>>    { return error === null; }
>>
>>    public String getError()
>>    { return error; }
>> }
>>
>> This isn't a really good example because Integer provides other ways of
>> doing the job, but it does illustrate the sort of scoping problem I'm
>> talking about: that of allowing access to the Integer instance in both
>> parts of the try/catch block as well as from surrounding parts of the
>> method body.
> 
>      I don't see how the NumberFormatException has much to do
> with it: Your getHeight() method needs the `h' at the point of its
> return, so its scope must include the return statement. The only
> "scoping issue" I can see is that the try block and the catch block have
> their own subsidiary scopes in which `h' also needs to be (and is)
> visible -- but then, why aren't you worried about the scope of `height'?
>  (Or even of `error' and `alt'?)
>
You're right, of course. But, please bear in mind that I concocted this 
example at Robert's request to illustrate the sort of scoping situation 
where I prefer to use a constructor that never throws an Exception plus 
an init() method that can throw one rather than a constructor that does 
it all but needs to throw an Exception if a recoverable error occurs in 
the constructor.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#24790

On 20.07.2013 23:18, Martin Gregorie wrote:
> On Sat, 20 Jul 2013 17:12:47 -0400, Eric Sosman wrote:
>
>> On 7/20/2013 3:12 PM, Martin Gregorie wrote:
>>> On Sat, 20 Jul 2013 19:46:16 +0200, Robert Klemme wrote:
>>>
>>>> On 19.07.2013 23:21, Martin Gregorie wrote:
>>>>> [...]
>>>>> I take the opposite approach to Robert over that for one reason: that
>>>>> the only way to report init errors in a constructor is to throw an
>>>>> Exception,
>>>>> which means the instance declaration often needs to go inside a
>>>>> try/catch block which can screw up scoping.
>>>>
>>>> In what ways does this screw up scoping?
>>>>
>>> Just that I often find that I need access to the instance outside the
>>> try/
>>> catch block containing the constructor call and I don't much like
>>> initialising the pointer as null.
>>
>>       Then ... don't initialize it.
>>
>> 	Thing thing;
>> 	try {
>> 	    thing = new Thing();
>> 	} catch (DooWopDooWopDooWopException ex) {
>> 	    logger.log(Level.SEVERE, "Eek!", ex);
>> 	    throw ex;
>> 	}
>> 	System.out.println(thing.getSwing());
>> 	...
>>
>> This form has the advantage that the compiler will complain if the
>> all-important `throw ex;' is forgotten, whereas initializing to null
>> would just get you an NPE.
>>
>>       Very occasionally there's a situation where you really do need
>> to use the null-ness of `thing' as an indication that construction
>> failed.  In that case, I'd still suggest not initializing:
>>
>> 	Thing thing;
>> 	try {
>> 	    thing = new Thing();
>> 	} catch (DooWopDooWopDooWopException ex) {
>> 	    logger.log(Level.SEVERE, "Eek!", ex);
>> 	    thing = null;
>> 	}
>> 	if (thing != null) {
>> 	    System.out.println(thing.getSwing());
>> 	else {
>> 	    System.out.println("It don't mean a thing");
>> 	}
>>
>> IMHO, situations like this are suggestive of a poorly-designed Thing
>> class (which you may be forced to endure), or of a method that's trying
>> to do too many things and might better be split up.
>>
>>> This is a result of my dislike of using Exceptions to signal anything
>>> except a fatal error and may well be a hangover from writing a lot of C
>>> in the past. A method that returns reference to a library class whose
>>> constructor can throw an exception, e.g. Integer, but does not itself
>>> return an exception requires this sort of structure:

No, this is not _required_.  It can be done differently.  Just one way:

   public int getHeight(String height) {
     try {
       final Integer h = new Integer(height);

       if (h < 0) {
         error = "Below MSL";
         return -1;
       }

       error = null;
       return alt = h;
     }
     catch (NumberFormatException e) {
       error = e.getMessage();
       return -1;
     }
   }

I think there are various aspects about this example class that are 
worth discussing other than the scoping topic.  But I don't want to go 
there as we are currently discussing scope.

I believe the scoping is not screwed up by the constructor throwing an 
exception but rather by your choice of how you access "h" in that example.

>>> public class Altitude {
>>>     int    alt   = 0;
>>>     String error = null;
>>>
>>>     /**
>>>      * Returning a negative number indicates an invalid height.
>>>      */
>>>     public int getHeight(String height)
>>>     {
>>>       Integer h = null;
>>
>>       Since this initialization is useless (the variable will
>> always be overwritten, exception or no), why even have it?
>>
>>>       try {
>>>         h = new Integer(height);
>>>         if (h < 0)
>>>           error = "Below MSL";
>>>       }
>>>       catch (NumberFormatException e)
>>>       {
>>>         error = e.getMessage(); h = new Integer(-1);
>>>       }
>>>
>>>       return alt = h.intValue();
>>>     }
>>>
>>>     public boolean isValid()
>>>     { return error === null; }
>>>
>>>     public String getError()
>>>     { return error; }
>>> }
>>>
>>> This isn't a really good example because Integer provides other ways of
>>> doing the job, but it does illustrate the sort of scoping problem I'm
>>> talking about: that of allowing access to the Integer instance in both
>>> parts of the try/catch block as well as from surrounding parts of the
>>> method body.
>>
>>       I don't see how the NumberFormatException has much to do
>> with it: Your getHeight() method needs the `h' at the point of its
>> return, so its scope must include the return statement. The only
>> "scoping issue" I can see is that the try block and the catch block have
>> their own subsidiary scopes in which `h' also needs to be (and is)
>> visible -- but then, why aren't you worried about the scope of `height'?
>>   (Or even of `error' and `alt'?)
>>
> You're right, of course. But, please bear in mind that I concocted this
> example at Robert's request to illustrate the sort of scoping situation
> where I prefer to use a constructor that never throws an Exception plus
> an init() method that can throw one rather than a constructor that does
> it all but needs to throw an Exception if a recoverable error occurs in
> the constructor.

If you concede that Eric is right here then you are basically saying you 
provided the wrong example.  The problem with these examples is that 
they do not convey the point you are trying to make.  So what do you 
*really* want to say?

Cheers

	robert

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

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

#24793

On 07/20/2013 04:12 PM, Martin Gregorie wrote:
[ SNIP ]

> This is a result of my dislike of using Exceptions to signal anything
> except a fatal error and may well be a hangover from writing a lot of C
> in the past.

You probably know this, in fact I'm sure you do, but in OOP exceptions 
are like 95% of the time used for everything but fatal errors. Well, 
maybe 98 or 99 percent of the time.

A method that returns reference to a library class whose
> constructor can throw an exception, e.g. Integer, but does not itself
> return an exception requires this sort of structure:
[ SNIP ]

To the larger question, which I snipped, I'd still have the constructor 
throw exceptions. It's just a method, and in this case a failure to 
build is significant - it rates an exception. I don't know why it would 
screw up scoping: I'd typically have the happy path inside the "try". If 
you make your "try" blocks too small then you're defeating the purpose 
and introducing unnecessary "is this thing null" checks.

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]

#24794

On 7/21/2013 12:18 PM, Arved Sandstrom wrote:
> To the larger question, which I snipped, I'd still have the constructor
> throw exceptions. It's just a method, and in this case a failure to
> build is significant - it rates an exception. I don't know why it would
> screw up scoping: I'd typically have the happy path inside the "try". If
> you make your "try" blocks too small then you're defeating the purpose
> and introducing unnecessary "is this thing null" checks.

I wonder if the syntax is an issue here.  Part of the reason lambdas are 
being developed is to correct a "horizontal problem and vertical 
problem" in Java code.  That is, it takes a fair number of lines of 
source code to create a fairly simple anonymous class, and that's seen 
as a problem by a lot of people.

Perhaps something that removes some of the "vertical problem" in try 
catch statements would be useful.  Transforming this:

public Object someMethod( Object... params ) {
   try ( stuff... )
   {
      more stuff...
   }
   catch( stuff ) {
   }
}

Into something like this:

public Object someMethod( Object... params ) {

   stuff...
   more stuff...

   return;
   catch( stuff ) {
   }
}

Might remove some of the visual clutter in using try catch statements. 
Obviously this only works for top-level try-catch statements, but I 
think keeping things simple is the best idea.


Moving to a different idea, I also wonder if it's possible to define a 
lighter weight exception method that's more suited to "a quick 
check/non-return value" than building a full exception, which I believe 
can be very heavy weight (like, an order of magnitude more expensive to 
return an exception rather than a simple value).

So maybe something like this

public void : int checkedMethod( Object... params ) {
   ...
}

Where the "void:" syntax is taken to mean "nothing, or" some return 
value.  The idea here is that the compiler should insert the test for 
"void" (nothing, the error value) so the programmer doesn't have to 
remember to test a flag or some special return code.  This provides the 
light weight advantages of a return code with out the fragility of a 
programmer having to remember to test the return code.

I'm not sure exactly how to implement this, though.  Some thoughts:

1. If the programmer doesn't test the return value, then an Error is 
thrown.  This builds a stack frame, because you want to know who isn't 
testing for return values.

2. A special if test is allowed to test for invalid return values.  This 
provides fine grained testing.

3. A special catch pattern is allowed to test for "void:" return values. 
  This provides for coarser grained recovery when you want all 
statements with a void: return value to do the same thing.

Alternately #1 could be a compile error instead of a runtime check. 
Actually, this might be the better idea.


#2 Example

   int i;
   if( void : i = checkedMethod() ) {
     // "void:" return code, error processing here...
   } else {
     // i was assigned a value here
   }

#3 Example

   try {
     int i = checkedMethod();

     // lots o' statements...

   } catch( void ) {
     // error processing here
   }



...Just random thoughts by Y.T.

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

#24796

On 7/21/2013 3:18 PM, Arved Sandstrom wrote:
> On 07/20/2013 04:12 PM, Martin Gregorie wrote:
> [ SNIP ]
>
>> This is a result of my dislike of using Exceptions to signal anything
>> except a fatal error and may well be a hangover from writing a lot of C
>> in the past.
>
> You probably know this, in fact I'm sure you do, but in OOP exceptions
> are like 95% of the time used for everything but fatal errors. Well,
> maybe 98 or 99 percent of the time.

     (Eighty-seven point three percent of cited statistics are
plucked out of thin air.  ;-)

     One problem is that "fatal" is ill-defined.  Is an NPE
"fatal?"  Quite often it is, but sometimes the application
is prepared to cope with it -- For example, think of some
code throwing NPE while being managed by an IDE's debugger,
of think of a servlet throwing NPE without taking down the
entire Web container.

     Somewhere toward the other end of the spectrum, is a
NumberFormatException "benign?"  Maybe, if the application
can protest and prompt for another number.  Or maybe not,
if the string came from a configuration file and there's
nobody to respond to a prompt.

     The "seriousness" of an exception is not a function of
the exception itself, but of the code that catches (or fails
to catch) it.

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

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

#24797

On 07/21/2013 05:58 PM, Eric Sosman wrote:
> On 7/21/2013 3:18 PM, Arved Sandstrom wrote:
>> On 07/20/2013 04:12 PM, Martin Gregorie wrote:
>> [ SNIP ]
>>
>>> This is a result of my dislike of using Exceptions to signal anything
>>> except a fatal error and may well be a hangover from writing a lot of C
>>> in the past.
>>
>> You probably know this, in fact I'm sure you do, but in OOP exceptions
>> are like 95% of the time used for everything but fatal errors. Well,
>> maybe 98 or 99 percent of the time.
>
>      (Eighty-seven point three percent of cited statistics are
> plucked out of thin air.  ;-)
>
>      One problem is that "fatal" is ill-defined.  Is an NPE
> "fatal?"  Quite often it is, but sometimes the application
> is prepared to cope with it -- For example, think of some
> code throwing NPE while being managed by an IDE's debugger,
> of think of a servlet throwing NPE without taking down the
> entire Web container.
>
>      Somewhere toward the other end of the spectrum, is a
> NumberFormatException "benign?"  Maybe, if the application
> can protest and prompt for another number.  Or maybe not,
> if the string came from a configuration file and there's
> nobody to respond to a prompt.
>
>      The "seriousness" of an exception is not a function of
> the exception itself, but of the code that catches (or fails
> to catch) it.
>
No argument from me as to anything you said. An exception is just an 
event that requires special processing, which as you say can range from 
benign (NumberFormatException in a human-supplied input) through sorta 
bad (NumberFormatException in a value read in from a .properties file, 
but the program can use a default and log an error) [1], to something 
demonstrably showstopping like not having DB access to the data that you 
need to work with.

What it all boils down to is, I'd rather have a program that identifies 
a serious problem, saves work, and requests to shut down, than one that 
just breaks.

Having opined all that, I still consider a "fatal" problem to be one 
that, even though the programmer has correctly coded for all 
eventualities, is something that must terminate the program.

AHS

1. Adapting some of your examples.

-- 
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]

#24777

On 19.07.2013 04:21, Arved Sandstrom wrote:
> On 07/14/2013 01:03 PM, Robert Klemme wrote:
>> On 10.07.2013 00:46, Richard Maher wrote:

>>> So let me ask you "Why do you want to use setters or an init() method?"
>>
>> I opted for the init() method OR factory method pattern.  Both are type
>> safe because in both cases a method in an interface needs to be
>> implemented.  Picking a constructor solely based on argument types has a
>> looser coupling between the contract and the implementation of it.  An
>> interface makes that coupling explicit.

> I'll be honest, Robert, personally I consider the behaviour of an object
> - the kinds of things you could specify in an interface - to be what the
> *initialized* object can (should) do.

Of course.  A factory instance can also be an initialized object.

> Often the best way to properly initialize an object is to call a
> constructor with arguments. That's what they are for. And to be honest
> once again, a ctor *is* an implementation thing, IMO: it's not the
> business of an interface to dictate how an implementation will
> initialize objects that can support the interface contract. After all,
> how can an interface even possibly imagine what the internal state of an
> initialized object, hence what ctor args are required, is?

In situations like Richard's (at least as I understand it) the 
environment knows what information it has available and the interface 
for the factory can be defined in such a way to pass data potentially 
needed or the data that the environment is willing to provide.  The 
factory implementation then can decide which part of that information is 
needed to create the instance and ignore the rest.  It's surely better 
to let the implementor of the construction process decide which 
information to use than the implementor of the environment (or call it 
"framework").

> No problem with factory methods, except they are for specific
> situations. And I think they also lean more towards implementation.

What "specific situations" do you have in mind?  As far as I can see the 
name of the class to create is configured and Richard said reflection 
will be used in his initial posting.  I think that is a typical 
situation where a factory class can be configured which is created via a 
no arg constructor and which has a method createFoo(...) with 
appropriate arguments.  Then there is no need to fiddle with reflection 
to analyze constructors and argument lists.  Also, this gives more 
flexibility as the factory can decide which class to instantiate at 
runtime if need be.

My main point is that I dislike using reflection to _find_ an 
appropriate method - be it a constructor or another method.  I prefer 
that method to be identified in an interface - whether that is an init() 
method in the interface of the object I will eventually be using or a 
create() method in another interface defining the factory API I care 
less.  I think Class.forName() and newInstance() is enough reflection to 
get flexibility and decoupling but from there on I prefer to use methods 
specified via an interface or abstract base class.

Kind regards

	robert

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

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

#24778

On 20.07.2013 20:09, Robert Klemme wrote:
> On 19.07.2013 04:21, Arved Sandstrom wrote:
>> On 07/14/2013 01:03 PM, Robert Klemme wrote:
>>> On 10.07.2013 00:46, Richard Maher wrote:
>
>>>> So let me ask you "Why do you want to use setters or an init() method?"
>>>
>>> I opted for the init() method OR factory method pattern.  Both are type
>>> safe because in both cases a method in an interface needs to be
>>> implemented.  Picking a constructor solely based on argument types has a
>>> looser coupling between the contract and the implementation of it.  An
>>> interface makes that coupling explicit.
>
>> I'll be honest, Robert, personally I consider the behaviour of an object
>> - the kinds of things you could specify in an interface - to be what the
>> *initialized* object can (should) do.
>
> Of course.  A factory instance can also be an initialized object.
>
>> Often the best way to properly initialize an object is to call a
>> constructor with arguments. That's what they are for. And to be honest
>> once again, a ctor *is* an implementation thing, IMO: it's not the
>> business of an interface to dictate how an implementation will
>> initialize objects that can support the interface contract. After all,
>> how can an interface even possibly imagine what the internal state of an
>> initialized object, hence what ctor args are required, is?
>
> In situations like Richard's (at least as I understand it) the
> environment knows what information it has available and the interface
> for the factory can be defined in such a way to pass data potentially
> needed or the data that the environment is willing to provide.  The
> factory implementation then can decide which part of that information is
> needed to create the instance and ignore the rest.  It's surely better
> to let the implementor of the construction process decide which
> information to use than the implementor of the environment (or call it
> "framework").
>
>> No problem with factory methods, except they are for specific
>> situations. And I think they also lean more towards implementation.
>
> What "specific situations" do you have in mind?  As far as I can see the
> name of the class to create is configured and Richard said reflection
> will be used in his initial posting.  I think that is a typical
> situation where a factory class can be configured which is created via a
> no arg constructor and which has a method createFoo(...) with
> appropriate arguments.  Then there is no need to fiddle with reflection
> to analyze constructors and argument lists.  Also, this gives more
> flexibility as the factory can decide which class to instantiate at
> runtime if need be.
>
> My main point is that I dislike using reflection to _find_ an
> appropriate method - be it a constructor or another method.  I prefer
> that method to be identified in an interface - whether that is an init()
> method in the interface of the object I will eventually be using or a
> create() method in another interface defining the factory API I care
> less.  I think Class.forName() and newInstance() is enough reflection to
> get flexibility and decoupling but from there on I prefer to use methods
> specified via an interface or abstract base class.

Adding one bit of reasoning: the reason I dislike the approach to find a 
method via reflection is that the contract is documented in text only 
("the class must have at least a constructor with these argument 
types...") whereas with an interface the contract is expressed in code 
as far as possible.  (With that I mean there are other languages which 
allow to define much more aspects of a contract in code, like Eiffel.) 
That makes better use of language features IMO.

Cheers

	robert


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

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

#24783

On Sat, 20 Jul 2013 20:09:00 +0200, Robert Klemme wrote:

> My main point is that I dislike using reflection to _find_ an 
> appropriate method - be it a constructor or another method.  I prefer 
> that method to be identified in an interface - whether that is an init() 
> method in the interface of the object I will eventually be using or a 
> create() method in another interface defining the factory API I care 
> less.  I think Class.forName() and newInstance() is enough reflection to 
> get flexibility and decoupling but from there on I prefer to use methods 
> specified via an interface or abstract base class.

While I have admittedly not followed the whole thread too closely, how
about this ?

public interface Bla {
  public void setBlurg(int newBlurg);

  public int getBlurg();

  public Bla getInstance(int param, float difParam, Socket sockParam);
}

No more need for Reflection to search for something. On the implementation
level, getInstance can still decide to discard unneccessary parameters.

Liebe Gruesse,
		Joerg

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

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

#24786

On 7/20/2013 5:17 PM, Joerg Meier wrote:
>[...]
> While I have admittedly not followed the whole thread too closely, how
> about this ?
>
> public interface Bla {
>    public void setBlurg(int newBlurg);
>
>    public int getBlurg();
>
>    public Bla getInstance(int param, float difParam, Socket sockParam);
> }
>
> No more need for Reflection to search for something. On the implementation
> level, getInstance can still decide to discard unneccessary parameters.

     Since you already need an instance of a class implementing
Bla before you can call getInstance() on it, what's the point?

     Perhaps you meant the interface to be BlaFactory (with getInstance()
still returning Bla)?

	BlaFactory factory = BlaFactoryProvider.defaultFactory();
	factory.setBlurg(86);
	Bla instance = factory.getInstance(42, 42.0, null);

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

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

#24788

On Sat, 20 Jul 2013 17:32:09 -0400, Eric Sosman wrote:

> On 7/20/2013 5:17 PM, Joerg Meier wrote:
>>[...]
>> While I have admittedly not followed the whole thread too closely, how
>> about this ?
>>
>> public interface Bla {
>>    public void setBlurg(int newBlurg);
>>
>>    public int getBlurg();
>>
>>    public Bla getInstance(int param, float difParam, Socket sockParam);
>> }
>>
>> No more need for Reflection to search for something. On the implementation
>> level, getInstance can still decide to discard unneccessary parameters.
>      Since you already need an instance of a class implementing
> Bla before you can call getInstance() on it, what's the point?

>      Perhaps you meant the interface to be BlaFactory (with getInstance()
> still returning Bla)?

> 	BlaFactory factory = BlaFactoryProvider.defaultFactory();
> 	factory.setBlurg(86);
> 	Bla instance = factory.getInstance(42, 42.0, null);

You are right, of course. That's what I get for thinking I found a better
solution based on skimming a topic ;) I simply didn't think it through.

Liebe Gruesse,
		Joerg

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

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

#24795

On 07/20/2013 03:09 PM, Robert Klemme wrote:
> On 19.07.2013 04:21, Arved Sandstrom wrote:
>> On 07/14/2013 01:03 PM, Robert Klemme wrote:
>>> On 10.07.2013 00:46, Richard Maher wrote:
>
>>>> So let me ask you "Why do you want to use setters or an init() method?"
>>>
>>> I opted for the init() method OR factory method pattern.  Both are type
>>> safe because in both cases a method in an interface needs to be
>>> implemented.  Picking a constructor solely based on argument types has a
>>> looser coupling between the contract and the implementation of it.  An
>>> interface makes that coupling explicit.
>
>> I'll be honest, Robert, personally I consider the behaviour of an object
>> - the kinds of things you could specify in an interface - to be what the
>> *initialized* object can (should) do.
>
> Of course.  A factory instance can also be an initialized object.

I would hope that it would usually be. But since Socket got mentioned, 
we see that that is not always the case.

But I have no aversion to factory methods.

>> Often the best way to properly initialize an object is to call a
>> constructor with arguments. That's what they are for. And to be honest
>> once again, a ctor *is* an implementation thing, IMO: it's not the
>> business of an interface to dictate how an implementation will
>> initialize objects that can support the interface contract. After all,
>> how can an interface even possibly imagine what the internal state of an
>> initialized object, hence what ctor args are required, is?
>
> In situations like Richard's (at least as I understand it) the
> environment knows what information it has available and the interface
> for the factory can be defined in such a way to pass data potentially
> needed or the data that the environment is willing to provide.  The
> factory implementation then can decide which part of that information is
> needed to create the instance and ignore the rest.  It's surely better
> to let the implementor of the construction process decide which
> information to use than the implementor of the environment (or call it
> "framework").

You know, I'd call that a 50/50, I think sometimes the caller is the 
best judge, and sometimes the callee is.

>> No problem with factory methods, except they are for specific
>> situations. And I think they also lean more towards implementation.
>
> What "specific situations" do you have in mind?  As far as I can see the
> name of the class to create is configured and Richard said reflection
> will be used in his initial posting.  I think that is a typical
> situation where a factory class can be configured which is created via a
> no arg constructor and which has a method createFoo(...) with
> appropriate arguments.  Then there is no need to fiddle with reflection
> to analyze constructors and argument lists.  Also, this gives more
> flexibility as the factory can decide which class to instantiate at
> runtime if need be.

Specific situation? The very essence of a factory method - you need to 
create an object that can do such-and-such, but you don't (for one 
reason or another), or can't, specify the exact class of the object to 
be created.

By definition, if you *do* know exactly what you want to create, and 
have appropriate constructors to do it with, why resort to a factory method?

> My main point is that I dislike using reflection to _find_ an
> appropriate method - be it a constructor or another method.  I prefer
> that method to be identified in an interface - whether that is an init()
> method in the interface of the object I will eventually be using or a
> create() method in another interface defining the factory API I care
> less.  I think Class.forName() and newInstance() is enough reflection to
> get flexibility and decoupling but from there on I prefer to use methods
> specified via an interface or abstract base class.
>
> Kind regards
>
>      robert
>
I'd differentiate between the use of reflection to find a method 
(including ctors) and the more general discussion we strayed into, which 
is simply when do you use ctors or factory methods or whatever.

In the last 5 years I think I've extensively used reflection in Java 
_twice_. In one case, as I mentioned previously in this thread, it was 
for construction of non-JPA entity result objects for native queries; I 
adapted a third party class to modify and adapt how it searched for 
constructors, but otherwise it was a reasonable use...compared to the 
alternative.

In the other case I had to write a "command server" because of the 
erstwhile fork+exec problem on Solaris, where RAM would get hammered. 
This server basically took on the job of executing system programs 
through Runtime and Process, running in a much smaller heap than the 
calling apps. Because of it's very nature, it had to load or unload 
command classes at runtime, and these classes did have to be written to 
an interface. No need for specifying how they constructed themselves though.

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]

#24720

On 7/9/2013 3:41 AM, Richard Maher wrote:

> Most people I have consulted recommend going the null Constructor in
> combination with Setters, or an INIT() method, to communicate the

Well, that's something to consider.  Personally, I don't see much 
difference, although you've given us no details as to what you are 
actually doing here, or any particulars at all.  If most people you 
consult say not to do something, maybe they know something we don't.

You may wish to compare with Java's DriverManager, which will load and 
configure a class based on a single init string.

DriverManager.getConnection( "jdbc:vendor://username:password"
		+ "@domain:port/schema",
                    connectionProps);

That isn't terrible, but it's not particularly elegant either, and your 
colleagues may be concerned with maintenance issues, or other things.

I think you should forget reflection loading, and use a regular factory 
if at all possible. Even better is to not use a factory and just access 
the class directly.  Is there a reason you can't just name the class and 
use it?  You're certain the actual class file must be supplied at 
runtime, and can't possibly known at compile time?

What do you envision the API to load this class looks like?  The public 
one your colleagues will see, not your internal implementation.

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

#24723

On 7/10/2013 9:13 AM, markspace wrote:
>
> I think you should forget reflection loading, and use a regular factory
> if at all possible. Even better is to not use a factory and just access
> the class directly.  Is there a reason you can't just name the class and
> use it?  You're certain the actual class file must be supplied at
> runtime, and can't possibly known at compile time?

I do not supply the class to be loaded I just require that the Interface 
be implemented and that the class is part of the Tier3Client package.
>
> What do you envision the API to load this class looks like?  The public
> one your colleagues will see, not your internal implementation.

I am adding a new argument HandShake {archive : "myJAR.jar", class : 
"logon"} to my Tier3Client Javascript class. If it's not there at 
run-time then the default login Handshake will be used, otherwise it 
will be appended to the Applet's Archive list and appear on the CP. The 
class will be loaded by Class.forName(appletParam).

Just to sexy for words!!!

An before you get up to your old nervous Nelly tricks and FUD about 
"There be dragons" let me tell you that it all works with an unsigned 
Applet.

Cheers Richard Maher

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

#24725

On 7/10/2013 3:03 AM, Richard Maher wrote:
> I am adding a new argument HandShake {archive : "myJAR.jar", class :
> "logon"} to my Tier3Client Javascript class. If it's not there at

If you're the only one who will see this, then you can certainly do as 
you like.  I might suggest one single "Handshake" class, however, which 
you supply in a required Jar file.  Then to provide something other than 
the default (which lives in its own Jar file), you just swap that Jar 
file for another one.

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

#24727

On 7/10/2013 11:41 PM, markspace wrote:
> On 7/10/2013 3:03 AM, Richard Maher wrote:
>> I am adding a new argument HandShake {archive : "myJAR.jar", class :
>> "logon"} to my Tier3Client Javascript class. If it's not there at
>
> If you're the only one who will see this, then you can certainly do as
> you like.  I might suggest one single "Handshake" class, however, which
> you supply in a required Jar file.  Then to provide something other than
> the default (which lives in its own Jar file), you just swap that Jar
> file for another one.
>
>
Yep, you got it.

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

#24721

On 7/9/13 3:41 AM, Richard Maher wrote:
> Hi,
>
> I have an interface that requires an implementer to cut code that 99%
> sure is going to need some variables that are built at run-time. The
> class to be developed will also be loaded at run-time via Reflection.
>
> Most people I have consulted recommend going the null Constructor in
> combination with Setters, or an INIT() method, to communicate the
> ambient variables to the loaded class. I, on the other hand, would like
> to go the Constructor-Injection-esque root of attempting to invoke a
> version of the Contstructor with the arguments I specify. (Maybe
> failover to null constructor on InvocationException) Is there something
> intrinsically wrong with doing this in Java? (I know there are Abstract
> Classes but I have only Abstract Methods.)
>
> If you like to know the real example then what I'd like to pass to the
> Constructor is the ParentFrame and an Application name.
> London-to-a-brick the callee will create a Dialog Box.
>
> Cheers Richard Maher

Perhaps you need two interfaces instead. A factory interface, and the 
actual business object interface.

Another way to handle this is to have some sort of injection where you 
pass in only objects the class requires. For instance, Guice will let 
you annotate a class and it will manage creating the instance for you, 
injecting any objects (either via constructors or setters) that the 
object needs.  Spring beans will do similar things, but is more common 
in web frameworks than GUIs.

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

#24722

On 7/10/2013 12:41 PM, Daniel Pitts wrote:
> On 7/9/13 3:41 AM, Richard Maher wrote:
>
> Another way to handle this is to have some sort of injection where you
> pass in only objects the class requires. For instance, Guice will let
> you annotate a class and it will manage creating the instance for you,
> injecting any objects (either via constructors or setters) that the
> object needs.  Spring beans will do similar things, but is more common
> in web frameworks than GUIs.
>

I've settled on a compromise. I will attempt to pass a single argument 
"sessionAmbience" to the loaded class and if I get a MethodNotFound et 
al Exception then I'll degrade to an empty Constructor.

The Tier3SessinAmbience Interface will describe all of the getters that 
are available to the loaded class to assist in providing the 
functionality that is required to implement the first Interface I 
described in the OP. If the user's code doesn't need all of the lovely 
goodies available for context then that's fine.

Cheers Richard

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web