Hi Brian,
the main driver behind declaring classes and methods final had not been
performance. Instead I wanted to introduce design contracts where Castor
is intended to be extended. I am aware that this may cause trouble for
those that extended Castor in a way I didn't thought off. In such cases
we are willing to make these classes extendable again by removing the
final restriction or create a public extension point. Even if we have to
remove the restriction again, the advantage is that we get aware of
those extensions. Having said that we had controvers discussion about
declaring classes final in the past and I had been the one that
introduced most of these restriction. I hope that I got it right that
you are talking about removal of some final restrictions and not about
removing them in general.
In my opinon the best option for you and your customer would be to add
his custom changes into Castor's codebase. This would prevent him to
merge his changes with new releases of Castor again and again. This may
also include to define extension points like configurable class
factories if the changes are only of use for your customer or does
interfer with our target to get JAXB 2.1 compliant in the near future.
Regards
Ralf
Brian Topping schrieb:
Howdy all,
I'm working with a company that has forked Castor XML and codegen from
version 0.9.5 in their main generation framework and want to bring it
up-to-date. I have two options... to roll their accumulated changes
across to the latest version and reapply them, or try to do a better
strategy based on subclassing, configuration changes and/or creation of
configurable class factories in Castor. I'm not too concerned at this
point about the general acceptance of these changes yet though.
Of immediate concern is the extensive use of the final keyword on
classes in Castor... those classes cannot be extended without forking.
So I'm wondering how receptive the Castor team would be to removing
those restrictions. If there are speed concerns, I would be willing to
do quantitative testing to measure speed differences between current
and proposed changes.
Any thoughts? It would be a great day if we could start getting
updates from the central repo!
Thanks kindly,
Brian
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
