Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 65585 invoked from network); 17 Jun 2002 01:37:16 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 17 Jun 2002 01:37:16 -0000 Received: (qmail 29645 invoked by uid 97); 17 Jun 2002 01:37:27 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 29605 invoked by uid 97); 17 Jun 2002 01:37:26 -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 29593 invoked by uid 98); 17 Jun 2002 01:37:26 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Sun, 16 Jun 2002 21:36:56 -0400 From: Dmitri Plotnikov Subject: Re: [reflect] Proposals: To: Jakarta Commons Developers List Message-id: <020001c2159f$77e64c00$0200a8c0@GATEWAY> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <019c01c2158d$12073730$0200a8c0@GATEWAY> <003301c21596$51507420$833729d9@oemcomputer> 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 still think we'd be better of with a more catchy name: (jin) > My personal experience - when I first looked at commons I could see > beanUtils and collections, logging and http client and I knew what they did > so I took a look. I simply didn't look at the others at first, 'Cactus' or > 'Latka' may be catchy names but they tell the casual glancer nothing. Good point. > Stephen (going to bed...) - Dmitri (going to watch TV) > > ----- Original Message ----- > From: "Dmitri Plotnikov" > To: "Jakarta Commons Developers List" > Sent: Monday, June 17, 2002 12:25 AM > Subject: Re: [reflect] Proposals: > > > > How about this: we make this thing explicitly multi-level. For example, > we > > could have > > > > org.apache.commons.reflect > > > > for the convenience stuff Ola is describing. > > > > Then, separately, we could have > > > > org.apache.commons.reflect.introspect > > > > for the framework that builds on ...reflect and provides similar > > conveniences for all kinds of introspection. Perhaps that's where Steve's > > rules belong. > > > > > > I still think we'd be better of with a more catchy name: > > > > org.apache.commons.jin.reflect > > org.apache.commons.jin.introspect > > > > > > - Dmitri > > > > ----- Original Message ----- > > From: "Ola Berg" > > To: > > Sent: Sunday, June 16, 2002 3:51 PM > > Subject: [reflect] Proposals: > > > > > > > Dimitri wrote: > > > >Perhaps I misunderstood what the proposal was all about. My > understanding > > > >was that it was after introspection rather than pure reflection. When I > > > >hear the word \"reflection\", the list of features that comes to my > mind > > is: > > > > > > No, I don\'t think you misunderstood. Hey, we are trying to make > something > > new here, the limits aren\'t set, borders ain\'t drawn. > > > > > > Reflection in JVM is basically set and very low level. What people > already > > do with reflection/introspection is useful and often very high level. I > > challenged your proposal by trying to draw a sketchy level for this new > > package, placing it somewhere in the middle: make reflection utility for > > often-needed mechanisms, thus supporting (as opposed to implementing) a > lot > > of high level stuff. > > > > > > Using Java reflection is straight forward, once you have the right > Method > > objects. I believe that the low level operations in the package should > deal > > with these two issues: > > > > > > 1) Means to easily select the right set of Methods (hopefully > > dynamically), and defining groups or categories of Methods (just like > > setters are one category of Methods) with some kind of Method category > > definition (a Rule, a Predicate, whatever) > > > > > > 2) Caching of the reflection look-up results, for performance issues. > > > > > > These two are very low-level issues with java.lang.reflect, but I > believe > > important ones. > > > > > > The second question is how high this package should go (in terms of > > \"levels\"), still maintaining a good separation of concerns. Maybe the > > ideas we come up with will result in different packages at different > levels, > > who knows? > > > > > > > > > Anyway: don\'t limit your thoughts based on anything I come up with. My > > personal signal-to-noise ratio is low, I admit that... > > > > > > > > > /O > > > > > > -------------------- > > > ola.berg@arkitema.se > > > 0733 - 99 99 17 > > > > > > -- > > > To unsubscribe, e-mail: > > > > > For additional commands, e-mail: > > > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > > > For additional commands, e-mail: > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: