Re: Re-precating (?) classes (was: RE: What is a Parser?)

[Nicola Ken Barozzi]

Berin Loritsch wrote:

Nicola Ken Barozzi wrote:

Peter Donald wrote:

On Thu, 30 Jan 2003 08:05, Leo Sutic wrote:

I'd just like to see what you in Avalon-dev have to say about this:

Update Cocoon to latest Avalon code and remove Component from the Cocoon codebase (A 30 min job?) and the deprecation warnings will go away.

Right.

We have to provide full backward compatibility in 2.x series; all Components and Composables must be honored; core interfaces like Generator, Transformer, Serializer all extend Component and this can not be changed.

Keep in mind the following:

#1 The Composables *will* be honored.
#2 The Component interface does *not* add any functionality.  It can
   also be added _dynamically_.
#3 We can safely remove the Component interface (the source for most
   deprecation warnings).
#4 We can move to using the Serviceable components instead of the
   Composables so that all _Cocoon_ code can properly mark deprecation
   on components itself without any deprecations comming from the Avalon
   code.

What about all the client code that checks for Component and won't find it in the Cocoon components, and the ones that extend Cocoon components?

All this can be done with the current CVS version of ECM and Fortress.
Currently it requires JRE 1.3 or higher.  If JRE 1.3 is unnacceptable,
then *please* let us know, and we will make ECM 1.2 compatible by using
the CGLIB library with a drop in replacement for JRE 1.3 dynamic
proxies.

You'll have to ask cocoon-dev ;-)

I'm personally in favor of keeping 1.2 compat unless impossible. Don't know if Cocoon now can really still compile with 1.2 though.

This will make sense for 3.0.

It even makes sense in the real short term.  As soon as ECM is released,
you will be able to use the *same* code, and not worry about the
Component/Composable interfaces.  They *will* be supported.

Actually, I'd like to see the upgrade to Fortress, it seems many are interested.

As Vadim pointed outm, OTOH, timing for such changes is really not good - we just have 3 books published recently.

And another one that should be done around April (for Avalon and
component oriented programming).

Then it's even worse! ;-)

From an engineering POV removing @deprecated sucks. But it's also true that from a user perspective, having deprecation warnings on core Cocoon components, ant that is all of them simce we use Avalon heavily, sucks even more.

The user won't have to worry about them.

I'm mildly in favor of removing the @deprecation tag and putting it in the docs, but I'm not sure either.

I'm not.  We just need an ECM released RSN.  THe Avalon team is putting
together releases for everything.  We just need to know if it is
acceptable with the Cocoon folks if JRE 1.3 is the minimum or not.

Ok. Please lead in this, I will follow.

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]