> From: Gregory Steuck [mailto:[EMAIL PROTECTED]] > > > I really like Berin's suggestion re Requests. The only con, > that Leo already mentioned, is an extra indirection level and > growth of the code that uses such new component managers.
Actually, the code shrinks. We are trading one method call for a bunch of exception handling code. The tradeoff is in favor of the indirection! > > >>>>> "Peter" == Peter Donald <[EMAIL PROTECTED]> writes: > > >> That's a lot of Generator.ROLE + "/fooo"! > > Peter> Put the key in a static at top of class (or cache it in > Peter> some other way) and that would be a lil better. Though > Peter> caching all strings would be a much better improvement > Peter> IMHO. > > You still pay the price of hashing the string on lookups. I > don't think they keep the hash value in the String once > calculated. And since String is a final class you can't do > anything about that. It doesn't. I've looked at the source code. For an object that isn't supposed to change (String is supposed to represent a static value), I find that quite amazing. > > Peter> Can you give me one solid reason why it needs to be done at > Peter> runtime in 99% of cases? I will grant you that runtime > Peter> assembly may be necessary when components looked up are > Peter> determined by request data but in other cases? > > The component in question needs to be: > > * expensive to construct > * single threaded > * often used for short periods of time > > Can anybody name such a component? Something similar to a > database server will do ;-) > > -- > To unsubscribe, e-mail: > <mailto:avalon-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
