[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JBoss Reflection Questions

[alesj]

"flavia.rainone at jboss.com" wrote : 
  | - Why aren't the classes JavassistField, JavassistConstructor, JavassistMethod and JavassistReflectionFactory package-protected? Those names can be easily mistaken with JavassistFieldInfo, JavassistConstructorInfo, etc and they are only used inside their own package.
  | 
Looking at them now, I guess they could be moved to pckg protected.
But it was Adrian who did this piece.
I guess it's his call to try to stop you of doing this. :-)

"flavia.rainone at jboss.com" wrote : 
  | -What is MutableMethodInfoCommand for?
  | 
Looking at the one comment

  |    /**
  |     * TODO: something similar to CtBehavior.instrument(...)
  |     * /
  |    void executeCommand(MutableMethodInfoCommand mmc);
  | 
This is something Stale had in mind, but it looks like he never finished.

"flavia.rainone at jboss.com" wrote : 
  | -At JavassistTypeInfo, what do the TODOS like the one below mean?
  | //TODO: need to change the use of getType() here
  |    public boolean isCollection()
  |    {
  |       return Collection.class.isAssignableFrom(getType());
  |    }
  | I see that getType is deprecated. But what is the main idea behind this?
  | 
This TODO was meant in the sense of "try not to use getType".

Afair, the idea is to be able to handle all (ok, almost all) of the Reflect use cases w/o the need of getType.
Currently this is not exactly the case.
I hope Adrian can shed some more light on this subject.

"flavia.rainone at jboss.com" wrote : 
  | - Are the Javassist Expression interfaces needed? I mean, from http://www.jboss.org/index.html?module=bb&op=viewtopic&t=148169&postdays=0&postorder=asc&start=50,
  | It is clear they were created for JBoss AOP integration. And I also see that those interfaces were not even implemented. Is it that all, or there is another use case for those? Just trying to define the priority of filling in these blanks.
  | 
Yes, this was mainly to do proper Reflect abstraction for AOP.
e.g. not really relying on Javassist details

But yeah, this is not a priority.
Although it would be nice to finish this once. ;-)

"flavia.rainone at jboss.com" wrote : 
  | Plus, I've seen a TODO with  JBMICROCONT-132 at ValueConvertor class and this task was resolved in 2006. You left an open question on whether we should remove the support for value creation via constructor with one String parameter. Do you have an answer to this question?
  | 
I know Adrian and me once had this discussion.
I'll try to find it, but I think you can leave it for now.
It's been serving us OK so far ... :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237012#4237012

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237012