anonymous wrote : | I'll have to think about that one. It requires interaction with the classloader | which I definitly don't want to do in the xml parsing (the classloader may not | even exist at that point). |
A early binding of the FQN to a classloader, while nice and would be really cool, was not what I was thinking primarily. Even with late binding it would save the developer's fingers. Rather than having to repeat java.lang.String all over the place (actually this is a bad example, since it's always part of the JDK java.lang package I should never have to specify the package name by default, only if I decide to want to use acme.String from some other package), I'd like to just save myself from typing the same FQN in many locations. If I mess up the "import" (or "alias" or whatever you call it) and it fails at bind time, then I have one location to correct my mistake, instead of 10. If some or even all things can be bound at parse time, then that's even better. Some packages, such as java.* and some javax.* packages should be "imported" by default, and allow overwrite with a FQN where necessary (really the same if in java you import with * wildcard and then override type def with FQN). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3870773#3870773 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3870773 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
