cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Tue, 24 Sep 2002 14:45:07 GMT
Tom Klaasen wrote:
> ------------------------
> wrote:
> ------------------------

>>It's not that bad--not that pretty either.  However it allows us to
>>handle the Recyclable issues well.  Otherwise I have to use reflection
>>to determine if it implements
> You'd use instanceof, not reflection.

Not if the interface is not in the classpath while the pool is being
compiled!  Pool and MPool *must* not rely on each other.

>>What happens if I have
>>something similar in another framework?
> Another quick&dirty hack?

I hate hacks.  I had to rewrite an entire library because it was the
product of a ton of Q&D hacks.  A generic solution that works in most
cases is the best way to go.

>>>Just my opinion. We've got such a nice framework right now, with lots of good
design patterns incorporated, and I would hate to see it wasted in this way.
>>How is an isolated incident of properly applied reflection a waste?
> Reflection always seems "appropriate", but in most cases the guy who codes it just thinks
it's cool. I have fallen into this trap myself, and I have seen others falling into it also.
> If, however, you still think this is the way to go, who am I to stop you. Just consider
me the sign saying "steep ravine ahead". If you're skilled enough to descend that ravine,
by all means go ahead and do it. And a sign doesn't have any knowledge of the reasons why
you want to descend that ravine, and nor do I.
> But I'll repeat my sig ;-)

Could you put some line breaks in your messages?

I only use reflection when there is no better alternative.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:
For additional commands, email:

View raw message