[reflect] Proposals:

[Ola Berg <ol...@arkitema.se>]

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? 

<ola:self-criticism>
Anyway: don\'t limit your thoughts based on anything I come up with. My personal signal-to-noise ratio is low, I admit that...
</ola:self-criticism>

/O

--------------------
ola.berg@arkitema.se
0733 - 99 99 17

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [reflect] Proposals:

[Juozas Baliuka <ba...@centras.lt>]

Hi,
I think it is possible to decide about package names later.
1) Stephen, writes proposal and adds his code.
2) All, find code in jakarta about the same and  add the most interesting.
3) All, Eleminate dublication and useless code, decide about package names,
finalize proposal.
4) All, tests, docs .... .

> 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.
>
> <dmitri:nag>
> I still think we'd be better of with a more catchy name:
>
> org.apache.commons.jin.reflect
> org.apache.commons.jin.introspect
> </dmitri:nag>
>
> - Dmitri
>
> ----- Original Message -----
> From: "Ola Berg" <ol...@arkitema.se>
> To: <co...@jakarta.apache.org>
> 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?
> >
> > <ola:self-criticism>
> > Anyway: don\'t limit your thoughts based on anything I come up with. My
> personal signal-to-noise ratio is low, I admit that...
> > </ola:self-criticism>
> >
> > /O
> >
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [reflect] Proposals:

[Dmitri Plotnikov <dm...@apache.org>]

> > <dmitri:nag>
> > 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" <dm...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> 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.
> >
> > <dmitri:nag>
> > I still think we'd be better of with a more catchy name:
> >
> > org.apache.commons.jin.reflect
> > org.apache.commons.jin.introspect
> > </dmitri:nag>
> >
> > - Dmitri
> >
> > ----- Original Message -----
> > From: "Ola Berg" <ol...@arkitema.se>
> > To: <co...@jakarta.apache.org>
> > 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?
> > >
> > > <ola:self-criticism>
> > > Anyway: don\'t limit your thoughts based on anything I come up with.
My
> > personal signal-to-noise ratio is low, I admit that...
> > > </ola:self-criticism>
> > >
> > > /O
> > >
> > > --------------------
> > > ola.berg@arkitema.se
> > > 0733 - 99 99 17
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [reflect] Proposals:

[Stephen Colebourne <sc...@btopenworld.com>]

You may be right, two levels may yet be necessary/good. Once I can pull
together some of the requirements this may become more obvious.

> <dmitri:nag>
> 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.

Stephen (going to bed...)

----- Original Message -----
From: "Dmitri Plotnikov" <dm...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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.
>
> <dmitri:nag>
> I still think we'd be better of with a more catchy name:
>
> org.apache.commons.jin.reflect
> org.apache.commons.jin.introspect
> </dmitri:nag>
>
> - Dmitri
>
> ----- Original Message -----
> From: "Ola Berg" <ol...@arkitema.se>
> To: <co...@jakarta.apache.org>
> 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?
> >
> > <ola:self-criticism>
> > Anyway: don\'t limit your thoughts based on anything I come up with. My
> personal signal-to-noise ratio is low, I admit that...
> > </ola:self-criticism>
> >
> > /O
> >
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [reflect] Proposals:

[Dmitri Plotnikov <dm...@apache.org>]

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.

<dmitri:nag>
I still think we'd be better of with a more catchy name:

org.apache.commons.jin.reflect
org.apache.commons.jin.introspect
</dmitri:nag>

- Dmitri

----- Original Message -----
From: "Ola Berg" <ol...@arkitema.se>
To: <co...@jakarta.apache.org>
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?
>
> <ola:self-criticism>
> Anyway: don\'t limit your thoughts based on anything I come up with. My
personal signal-to-noise ratio is low, I admit that...
> </ola:self-criticism>
>
> /O
>
> --------------------
> ola.berg@arkitema.se
> 0733 - 99 99 17
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>