You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dmitri Plotnikov <dp...@yahoo.com> on 2002/10/28 17:12:21 UTC
[clazz] Clazz APIs Mock-up. Take II
Here's another iteration of Clazz APIs.
The basic changes:
1. I did away with the modelURI and all that nonsense. You should be
able to uniquely bind an object to its clazz. I don't think any more
that the idea that the same object can belong to multiple clazzes is
workable.
2. There is now a notion of ClazzLibrary, which produces and caches
Clazzes of a certain kind. ClazzLoaders are plug-ins into the
ClazzLibrary.
So, the basic algorithm is this:
Object something = ...;
Clazz clazz = Clazz.getClazz(something);
The implementation of getClazz does this:
for each clazzLibrary {
if (clazzLibrary.isMember(instance)){
return clazzLibrary.getClazz(instance);
}
}
The library may cache clazzes, but does not really have to. If it
does, it may do it like this:
String name = this.getClazzName(something);
Clazz clazz = (Clazz)cache.get(name);
if (clazz != null){
return clazz;
}
for each clazzloader {
if (clazzloader.isMember(something)){
clazz = clazzloader.getClazz(name);
name = clazz.getName();
cache.put(name, clazz);
return clazz;
}
}
throw ...;
ClazzLibraries are statically registered with Clazz
Clazzloaders are registered with ClazzLibraries
The whole point of separation between libraries and loaders is
performance. The idea is that we quickly determine which library the
object belongs to and let the corresponding library cache Clazzes if it
can.
3. I have added FieldAccessors we were discussing earlier
4. Added getDeclaredFields() and getDeclaredMethods()
5. Added "add" and "remove" methods to IndexedFieldAccessor.
I punted on the idea of handling Maps with the same mechanism as beans.
We may want to introduce another mechanism for those. The issue is
that there is very little type information on them. That said, a bean
can still be implemented as a map (see DynaBean).
- Dmitri
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: [clazz] Clazz APIs Mock-up. Take II
Posted by Berin Loritsch <bl...@apache.org>.
Steve Downey wrote:
> On Monday 28 October 2002 02:28 pm, Berin Loritsch wrote:
>
>>Dmitri Plotnikov wrote:
>>
>>>Here's another iteration of Clazz APIs.
>>
>>Without looking at the API itself, I like what you are describing
>>here. It seems intuitive. Now, my question is this. If I have
>>a ClazzLibrary or a ClazzLoader, can I perform something like this:
>>
>>ClazzLibrary loader = Clazz.getClazz( something ).getClazzLibrary();
>>Clazz[] implementingClazzes = loader.findClazzForAttribute(
>>"attribute-name" );
>>
>>
>>That would be excellent. (Substitute Property for Attribute if that
>>is what you want to call it).
>
>
> Properties are for objects, while Attributes are class invarients. [Question,
> is an attribute writeable?] They are somewhat analagous to static members, as
> properties are analagous to instance members.
Attributes are basically equivalent to class invariants. They are sets of
information that is directly associated with the Class/Method. Just like
all of the Class/Method information, this is determined at class load time.
> Before declarative programming was introduced, it would have made sense to
> subtype Class (if it wasn't final) to add attributes for a particular class.
> Being able to declare attributes at deployment time is very powerful, though.
> I've always been a bit surprised that the EJB spec didn't introduce a more
> general mechanism for it.
:) Yep.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz APIs Mock-up. Take II
Posted by Steve Downey <st...@netfolio.com>.
On Monday 28 October 2002 02:28 pm, Berin Loritsch wrote:
> Dmitri Plotnikov wrote:
> > Here's another iteration of Clazz APIs.
>
> Without looking at the API itself, I like what you are describing
> here. It seems intuitive. Now, my question is this. If I have
> a ClazzLibrary or a ClazzLoader, can I perform something like this:
>
> ClazzLibrary loader = Clazz.getClazz( something ).getClazzLibrary();
> Clazz[] implementingClazzes = loader.findClazzForAttribute(
> "attribute-name" );
>
>
> That would be excellent. (Substitute Property for Attribute if that
> is what you want to call it).
Properties are for objects, while Attributes are class invarients. [Question,
is an attribute writeable?] They are somewhat analagous to static members, as
properties are analagous to instance members.
Before declarative programming was introduced, it would have made sense to
subtype Class (if it wasn't final) to add attributes for a particular class.
Being able to declare attributes at deployment time is very powerful, though.
I've always been a bit surprised that the EJB spec didn't introduce a more
general mechanism for it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz APIs Mock-up. Take II
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> --- Berin Loritsch <bl...@apache.org> wrote:
>
>>Dmitri Plotnikov wrote:
>>
>>>Here's another iteration of Clazz APIs.
>>
>>Without looking at the API itself, I like what you are describing
>>here. It seems intuitive. Now, my question is this. If I have
>>a ClazzLibrary or a ClazzLoader, can I perform something like this:
>>
>>ClazzLibrary loader = Clazz.getClazz( something ).getClazzLibrary();
>>Clazz[] implementingClazzes = loader.findClazzForAttribute(
>>"attribute-name" );
>>
>
> This might be difficult if the library constructs/locates Clazzes on
> demand, but does not have an exhaustive list upfront.
>
> Another issue is that if the ClazzLoader is based on a ClassLoader, it
> may have to actually load all classes to search for the attribute.
> This may be problematic if you have too many classes or classes
> dependent on something absent from the classpath.
That might be an acceptible limitation. The way the Avalon containers
work is that they will load the classes before finding out information
from them.
>
> But it sure would be nice.
It sure would.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz APIs Mock-up. Take II
Posted by Dmitri Plotnikov <dp...@yahoo.com>.
--- Berin Loritsch <bl...@apache.org> wrote:
> Dmitri Plotnikov wrote:
> > Here's another iteration of Clazz APIs.
>
> Without looking at the API itself, I like what you are describing
> here. It seems intuitive. Now, my question is this. If I have
> a ClazzLibrary or a ClazzLoader, can I perform something like this:
>
> ClazzLibrary loader = Clazz.getClazz( something ).getClazzLibrary();
> Clazz[] implementingClazzes = loader.findClazzForAttribute(
> "attribute-name" );
>
This might be difficult if the library constructs/locates Clazzes on
demand, but does not have an exhaustive list upfront.
Another issue is that if the ClazzLoader is based on a ClassLoader, it
may have to actually load all classes to search for the attribute.
This may be problematic if you have too many classes or classes
dependent on something absent from the classpath.
But it sure would be nice.
<snip/>
- Dmitri
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Clazz APIs Mock-up. Take II
Posted by Berin Loritsch <bl...@apache.org>.
Dmitri Plotnikov wrote:
> Here's another iteration of Clazz APIs.
Without looking at the API itself, I like what you are describing
here. It seems intuitive. Now, my question is this. If I have
a ClazzLibrary or a ClazzLoader, can I perform something like this:
ClazzLibrary loader = Clazz.getClazz( something ).getClazzLibrary();
Clazz[] implementingClazzes = loader.findClazzForAttribute( "attribute-name" );
That would be excellent. (Substitute Property for Attribute if that
is what you want to call it).
>
> The basic changes:
>
> 1. I did away with the modelURI and all that nonsense. You should be
> able to uniquely bind an object to its clazz. I don't think any more
> that the idea that the same object can belong to multiple clazzes is
> workable.
>
> 2. There is now a notion of ClazzLibrary, which produces and caches
> Clazzes of a certain kind. ClazzLoaders are plug-ins into the
> ClazzLibrary.
>
> So, the basic algorithm is this:
>
> Object something = ...;
>
> Clazz clazz = Clazz.getClazz(something);
>
> The implementation of getClazz does this:
>
> for each clazzLibrary {
> if (clazzLibrary.isMember(instance)){
> return clazzLibrary.getClazz(instance);
> }
> }
>
> The library may cache clazzes, but does not really have to. If it
> does, it may do it like this:
>
> String name = this.getClazzName(something);
> Clazz clazz = (Clazz)cache.get(name);
> if (clazz != null){
> return clazz;
> }
>
> for each clazzloader {
> if (clazzloader.isMember(something)){
> clazz = clazzloader.getClazz(name);
> name = clazz.getName();
> cache.put(name, clazz);
> return clazz;
> }
> }
> throw ...;
>
> ClazzLibraries are statically registered with Clazz
> Clazzloaders are registered with ClazzLibraries
>
> The whole point of separation between libraries and loaders is
> performance. The idea is that we quickly determine which library the
> object belongs to and let the corresponding library cache Clazzes if it
> can.
>
> 3. I have added FieldAccessors we were discussing earlier
>
> 4. Added getDeclaredFields() and getDeclaredMethods()
>
> 5. Added "add" and "remove" methods to IndexedFieldAccessor.
>
> I punted on the idea of handling Maps with the same mechanism as beans.
> We may want to introduce another mechanism for those. The issue is
> that there is very little type information on them. That said, a bean
> can still be implemented as a map (see DynaBean).
>
> - Dmitri
>
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
>
> ------------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>