From: "Leo Simons" <[EMAIL PROTECTED]>
> > 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.
+1
> > 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.
+1
Consistency is important, since they have a similar meaning
role
subrole=role flavor=hint
> 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.
Premature optimization is the root of all evil.
Well, allmost ;-)
> 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.
Going down the real object road, it would have to be a type of object,
something like "Role".
This will hide the implementation.
Of course, making Role have a getRoleAsString() would be plain stupid, since
it would just shift the problem.
> 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.
For lookups, generally yes.
> > 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.
Premature optimization... bla bla bla
> 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.
Terrible idea.
When I call a method of the lifecycle, I give an order.
Since I assume that all that is to be done is execute that order, if he
fails, the order is not carried out.
I just need to know if it went through or not.
BBBZZZZZ... Wrong!
Anything can happen when the order is executed.
I repeat *anything*.
When an exception occurs, who will manage it?
Who is responsible?
The caller. -Always-
How can the caller be held responsible for it?
Catching the Exception.
> 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.
That can decide to rethrow it or handle it by other means.
But it needs to be held responsible.
> > Version 5 should include the following:
> >
> > * Clean room implementation--no deprecated methods/classes
>
> +1
+1
> > * Unified CM/SM (i.e. the interface above)
>
> +1, though not for that interface.
idem
> > * 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).
On James they had the opposite reaction.
They say that they don't want Avalon interfaces in the new Mailet API.
It just seems that org.apache.framework would keep them calm... go figure
:-S
> > * 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.
+1
> > - 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?
I think that having a DefaultXXX class is bad.
We should have only interfaces and factories in framework.
> > * Standard for Version info, and how we plan on handling that.
>
> yup. This is related to the meta-info stuff though.
+1
> > 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.
+1
> 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.
I think it's really important you remind this.
Remember guys, that if we make a revolution, we are going to loose our
users.
Definately.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
