RE: [primitives] Package layout strategy

2003-10-15 Thread Hope, Matthew
I had forgotten this - I agree something like pint, pboolean etc is cumbersome and counter-intuitive and would negate a significant reason for my suggestion so prob not worth it. -Original Message- From: Brent Worden [mailto:[EMAIL PROTECTED] Sent: 14 October 2003 00:55 To: Jakarta

RE: [primitives] Package layout strategy

2003-10-13 Thread Hope, Matthew
As a user I would point out that a likely use case would involve one primitive type but lots of different collections of that type. Would packaging by type work? I know it has negatives but if most of the code will be done via a template and code generation that it wouldn't be too bad perhaps?

RE: [primitives] Package layout strategy

2003-10-13 Thread Hope, Matthew
layout. I think a package that consists of all Maps will be easier to manage than a package consisting of all int collections, lists, maps, iterators, and sets. Hope, Matthew wrote: Is this really the case? The problem of primitives is that inheritance becomes impossible for a collection

RE: [digester] turning off commons-logging for unit tests

2003-10-01 Thread Hope, Matthew
Would suggest putting the resetting of the old logger in the tearDown() method... I have to do this a lot a the moment where all unit tests are run through irrespective of the result of others and this means you don't run any risk of losing the output. Finally will do the same but Junit provides

RE: [collections] CollectionUtils.index() behavior

2003-09-23 Thread Hope, Matthew
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: 21 September 2003 19:10 To: Jakarta Commons Developers List Subject: Re: [collections] CollectionUtils.index() behavior OK, I will leave as is, but I personally see this as bad design -- maps are not ordered Not so -

RE: [primitives] Open for business

2003-09-02 Thread Hope, Matthew
perhaps less so from 1.5 onwards since for non critical performance the ease of autoboxing is hard to beat but when you are using primitives not just because of other interface concerns but for performance/space considerations a pure primitive implementation should be considerably better for large

RE: [primitives] Open for business

2003-09-02 Thread Hope, Matthew
PROTECTED] Sent: 02 September 2003 12:03 To: Jakarta Commons Developers List Subject: Re: [primitives] Open for business - Original Message - From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 10:26

RE: [all] RuntimeExceptions, assertions, and pluggable validation

2003-08-27 Thread Hope, Matthew
Here's a rough idea: class AsserterFactory Asserter getAsserter(String name) interface Asserter void assertTrue(boolean condition, String message) class Java14Asserter void assertTrue(boolean condition, String message) assert condition : message;

RE: [collections]SingleElementCollection (was Questions....)

2003-08-21 Thread Hope, Matthew
()); } } -Original Message- From: Hope, Matthew Sent: 20 August 2003 15:16 To: 'Jakarta Commons Developers List' Subject: RE: [collections] Questions I knocked this up - javadocs are crap but is this the sort of thing you were thinking of? a mutable version is not too hard either

RE: [collections]SingleElementCollection (was Questions....)

2003-08-21 Thread Hope, Matthew
from:Hope, Matthew [EMAIL PROTECTED] inlined as attachment was stripped... import java.util.*; /** * Quick and simple implementation of a single element collection. The collection * starts with one entry and always keeps it that way, therefore modification

RE: [collections] Questions....

2003-08-20 Thread Hope, Matthew
-Original Message- From: Takuya Murata [mailto:[EMAIL PROTECTED] Sent: 20 August 2003 04:29 To: Jakarta Commons Developers List Subject: Re: [collections] Questions Hi, So the question is do we really need SingletonIterator and such. If we want to eliminate the

RE: [collections] Questions....

2003-08-20 Thread Hope, Matthew
-Original Message- From: Takuya Murata [mailto:[EMAIL PROTECTED] Sent: 20 August 2003 11:55 To: Jakarta Commons Developers List Subject: Re: [collections] Questions A tricky situation is class A { public void method (Iterator i); public void method (ListIterator

RE: [collections] Questions....

2003-08-20 Thread Hope, Matthew
I knocked this up - javadocs are crap but is this the sort of thing you were thinking of? a mutable version is not too hard either. Matt -Original Message- From: Hope, Matthew Sent: 20 August 2003 13:18 To: 'Jakarta Commons Developers List' Subject: RE: [collections] Questions

RE: StringUtils misspelled method names?

2003-08-14 Thread Hope, Matthew
We could fix the US spelling ;¬) seriously - is there a convention within apache / jakarta / commons to use US or UK english spelling? (or is it a case of consistency within sub project) Matt -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: 13 August 2003 18:57

RE: database connectivity

2003-08-14 Thread Hope, Matthew
I believe you are in the wrong mailing list for this. You have a classloader issue with your servlet container. this is nothing to do with commons. if you're using tomcat try the tomcat USER list however my best guess is that you haven't put the jdbc driver jar in the WEB-INF/lib/ directory...

RE: [io][vote] FileUtils: decision on style

2003-07-30 Thread Hope, Matthew
There's at least one person in this discussion who needs to extend the utils classes so it doesn't make sense to declare the classes final. How does it benefit anyone by declaring a reusable library class/method final? Preventing people who don't know what they are doing from making

RE: [io][vote] FileUtils: decision on style

2003-07-30 Thread Hope, Matthew
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: 30 July 2003 18:39 To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style Preventing people who don't know what they are doing from making mistakes. In my experience this

RE: [DBCP] AbandonedTrace - Connection Recovery

2003-07-24 Thread Hope, Matthew
-Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 12:52 To: Jakarta Commons Developers List Subject: Re: [DBCP] AbandonedTrace - Connection Recovery Logging is useless in this case, Such a statement seems ludicrous The relative merits of

RE: [DBCP] AbandonedTrace - Connection Recovery

2003-07-23 Thread Hope, Matthew
I did a lot of this kind of bugs myself too and it is very trivial to fix. 1. Set maxConnections to 1 for testing useful 2. Use lazy decorator for connection to throw exeption from close ??? 3. Use find/replace to remove all }finally{ connection.close(); } ??!?!?!?! 4. Store decorator in

RE: [DBCP] AbandonedTrace - Connection Recovery

2003-07-23 Thread Hope, Matthew
- From: Hope, Matthew [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:34 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery I would disagree on one point. The idea of logging when a connection is closed due to garbage

RE: [DBCP] AbandonedTrace - Connection Recovery

2003-07-23 Thread Hope, Matthew
I have only had a cursory read through this - using someone elses (hopefully better tested both in unit and real world) implementation is better than writing your own... ...however any system attempting to remove resource cleanup responsibilites from the developer either has to place extremely

RE: [DBCP] AbandonedTrace - Connection Recovery

2003-07-23 Thread Hope, Matthew
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 15:48 To: Jakarta Commons Developers List Subject: RE: [DBCP] AbandonedTrace - Connection Recovery --- Hope, Matthew [EMAIL PROTECTED] wrote: -Original Message- From: Glenn Nielsen [mailto

RE: [DBCP] AbandonedTrace - Connection Recovery

2003-07-22 Thread Hope, Matthew
I would disagree on one point. The idea of logging when a connection is closed due to garbage collection finalization strikes me as a good one (assuming the pool used is using a weakly referenced mapping otherwise garbage collection release of resources is going to be a real bummer). this kind of

RE: [lang] Pre 2.0 StringUtils NPE changes

2003-07-18 Thread Hope, Matthew
interesting problem... empty string has a very clear meaning in java, it is a non null String object of zero length. Does the entrenched user base merit retaining a non standard naming convention. or is Empty sufficiently entrenched to also mean null? (I don't think it is) I appreciate the

RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stringsa with somespaces

2003-07-15 Thread Hope, Matthew
As a user I agree with the benefits of both proposals (can't decide which I prefer yet). When I saw the initial proposal I wasn't happy either but could not come up with a 'complete' solution either. one point on the first though, I would find in my code that the vast majority of my use cases

RE: [lang] Pre 2.0 - StringUtils.isEmpty(), isNotEmpty() and stri ngsa with somespaces

2003-07-15 Thread Hope, Matthew
I see no reason for any of the methods we are talking about to distinguish x from xyz so lets simplify the set: I always use Empty to refer to never null - I am unaware of anyone doing any different. I normally use Whitespace to mean etc but NOT . I am aware some people differ in this. I am

RE: [math] Complex dilemmas

2003-06-06 Thread Hope, Matthew
A side question: even if Java permitted operator overloading, I have read comments to the effect that the technique is not to be preferred. Never having done much with it in a language that permits it, I don't have the experience to know why. As someone who thinks mathematically (at

RE: [BeanUtils] - Extensions for dotted queries...

2003-03-28 Thread Hope, Matthew
You are aware that the following two methods could not coexist in the same class? /** * A getter for a Map that maps the phoneType to the phoneNumber, * here represented by a String */ Map getPhone(); /** * A getter method for a Phone