Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 25118 invoked from network); 22 Aug 2002 00:20:02 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Aug 2002 00:20:02 -0000 Received: (qmail 555 invoked by uid 97); 22 Aug 2002 00:20:33 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 539 invoked by uid 97); 22 Aug 2002 00:20:32 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 527 invoked by uid 98); 22 Aug 2002 00:20:32 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Reply-To: From: "Steven Caswell" To: "'Jakarta Commons Developers List'" Subject: RE: [VOTE] (3b) XxxUtilsConstructors last chance Date: Wed, 21 Aug 2002 20:20:00 -0400 Message-ID: <004701c24971$a75542b0$2c00a8c0@YellowJacket> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I confess I'm a novice in the area of class loading. Can you elaborate a little more? What do you mean by "utility class extensions"? Steven Caswell steven@caswell.name a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." > -----Original Message----- > From: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com] > Sent: Wednesday, August 21, 2002 7:11 PM > To: Jakarta Commons Developers List > Cc: steven@caswell.name > Subject: Re: [VOTE] (3b) XxxUtilsConstructors last chance > > > "Steven Caswell" writes: > > > My vote is -0 instead of +0 because I haven't heard anyone > present a > > serious reason as to why a utility class, a non-bean, should be > > subject to subclassing. I can somewhat see the need for > construction > > for tools that require a bean (which a utility class really isn't), > > but I think other compromises, such as a wrapper class, > would also be > > reasonable. But again, no serious discussion on this topic was > > engaged. > > Class loading is a very useful feature. Preventing > sub-classing would effectively block the possibility of class > loading of utility class extensions. > -- > > Daniel Rall > > -- > To unsubscribe, e-mail: > unsubscribe@jakarta.apache.org> > For > additional commands, > e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: