Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 19968 invoked from network); 16 Jun 2002 23:25:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Jun 2002 23:25:35 -0000 Received: (qmail 14106 invoked by uid 97); 16 Jun 2002 23:25:44 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 14090 invoked by uid 97); 16 Jun 2002 23:25:44 -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 14078 invoked by uid 98); 16 Jun 2002 23:25:43 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Sun, 16 Jun 2002 19:25:15 -0400 From: Dmitri Plotnikov Subject: Re: [reflect] Proposals: To: Jakarta Commons Developers List Message-id: <019c01c2158d$12073730$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: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: