> I would like to create a scratchpad area/version 5.0 proposal area in
> Framework. Would we be ammendable to start creating the 5.0 area?
'course.
> I would like to include the CM we had the latest really long
> conversation
> about. I think 99% of us are on the same page.
>
> interface ComponentManager
> {
> /** throws ComponentException */
> Object lookup( String role );
>
> /** throws ComponentException */
> Object lookup( String role, Object hint );
>
> boolean exists( String role );
> boolean exists( String role, Object hint );
> }
nah. I still don't get why we need to use RuntimeExceptions. Also, I
can't see why we would have roles be strings, and then hints be objects.
It is either string or object, imo.
object vs string
================
The case you made for object is basically that it will bring higher
perfomance because 'stupid' users will do less expensive string creation
and the CM implementation can be optimized because it is no longer
neccessary to have a hash with strings as keys.
However, using objects can also mean creation of objects even more
expensive than strings (when you talk about 'stupid' users...), and the
hash will not be quicker. The real optimization would lie in using
primitives or their object counterparts (Long).
When we consider the added value of strings (easy for humans to read),
it seems hint should be a string.
RuntimeException vs declared Exception vs no exception
======================================================
The reason for using RuntimeExceptions instead of declared exceptions.
is that it saves the component writer a try/catch/finally block. The
disadvantage is that it is perfectly valid for lookup() to fail.
When the only reason for lookup() to fail is nonexistence of a requested
component, requiring a call of exists() before a lookup() removes the
need for a declared exception, or even a RuntimeException.
If we are sure that the only possible failure is a nonexistent component
then no exception at all is necessary if calling exists() is mandatory.
Is this true? I think so.
> Also, I would like to make as many of the exceptions to be
> RuntimeExceptions
> as possible. We should take a look at Stefano's concern for exception
> throwing.
some thoughts:
if a method call may fail, this should be indicated to the caller using
the language mechanism to indicate failure. In java, the way to do this
is by using the exception handling mechanism.
The problem raised by Stefano is that the exception handling mechanism
is not very performant as it requires the JVM to track state
information.
Is this problem large enough to warrant not using the java exception
handling mechanism as intended? I think the answer to that question
answers whether this is a good idea.
I have never written an application where any of the avalon framework
methods had any kind of negative impact on performance. Until there is
some actual perfomance data that makes clear the use of exceptions is a
performance problem, I think we should keep the exception throwing.
Note that the lifecycle methods throwing exceptions does not mean more
work for the component developer as the only thing that ever calls those
methods is the container.
> Version 5 should include the following:
>
> * Clean room implementation--no deprecated methods/classes
+1
> * Unified CM/SM (i.e. the interface above)
+1, though not for that interface.
> * Simplified package name
> - org.apache.avalon.**** ?
> - org.apache.framework.**** ?
+1. Some people will not like it if we use org.apache.framework (as
raised by -- I think -- Jason a few weeks ago).
> * Container abstraction
> - Meta data info
+1 if stable. Not a requirement -- this has no impact on the rest of the
framework so it can always be added in later as well.
> - Possible interface to have DefaultComponentManager defer all
> lookups to the Container
??
Like Stephen, I wonder whether defining a Container interface is a good
idea. Don't really see the need. Please elaborate?
> * Standard for Version info, and how we plan on handling that.
yup. This is related to the meta-info stuff though.
> How does this sound to everyone?
generally cool, though I think you make some assumptions about
agreements that I'm not sure exist. Each and every one of these bullets
needs a separate thread, discussion and vote.
Also, framework as it currently stands is pretty cool; there's no need
for revolutions; evolution is cool. We probably all agree, just wanted
to say that.
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
