Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 70197 invoked from network); 12 Aug 2002 23:55:34 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Aug 2002 23:55:34 -0000 Received: (qmail 14637 invoked by uid 97); 12 Aug 2002 23:56:02 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 14616 invoked by uid 97); 12 Aug 2002 23:56:01 -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 14604 invoked by uid 98); 12 Aug 2002 23:56:01 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Sender: dlr@finemaltcoding.com To: "Jakarta Commons Developers List" Subject: Re: [lang][collections] Utils having a public constructor References: From: Daniel Rall Date: 12 Aug 2002 16:55:40 -0700 Message-ID: Lines: 55 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N "Jack, Paul" writes: > > Velocity treats anything you put into its context in a bean-like > > fashion. I agree that StringUtils is not a JavaBean. Regardless, > > Velocity is able to use it in a bean-like fashion as long as there is > > an accessible ctor. What value is there in preventing this behavior? > > Allowing this behavior allows re-use of Commons code, which directly > > matches the charter under which Commons components operate. > > I guess I don't see the value in promoting the behavior. Giving > StringUtils a protected constructor just for Velocity seems like > a band-aid for a larger issue, which is that Velocity can't use > ANY library of static utility methods unless it has a public > constructor, which discounts many static libraries out there. > In the long run I think a change to Velocity would make more sense. Paul, this isn't a Velocity-only issue. Any bean-esque system which desired to use the utility classes would see the lack of protected or public constructor as a limitation in the Commons library. > There are valid reasons for keeping things as private as possible. > There are many cases in [collections] where bugs were found, or > where algorithms could be more efficient, but we couldn't change > the existing code because it exposed protected fields that we wanted > to delete, or because it used a protected method whose signature > we couldn't change because it would break backwards compatibility. I agree that information/implementation hiding is a good thing. I'm missing how this applies to addition of a constructor to classes consisting of static methods. > Having said that, I won't -1 any protected constructors in commons > utility classes, I'll just think they're really wierd. Fair enough. > And I really would consider allowing Velocity to invoke statics > without instances, as that really would give users greater > flexibility. I'll help if you'd like. :) Thanks for the offer. ;) The implementation of such a thing is trivial, but would break backwards compatibility. I mentioned that there are hooks for plugging in implementations which can have this sort of behavior. As I also mentioned to Stephen C., the behavior you suggest provides no way to indicate whether you want to invoke methods of the Class instance you add to the context, or methods of the class which it represents. I think this issue died a few messages ago, but we could certainly continue to beat it. In any case, it's nice to hear people's views. -- Daniel Rall -- To unsubscribe, e-mail: For additional commands, e-mail: