[Joda-interest] Re: Why are classes final in Joda 0.98?

[Stephen C. <ste...@ho...>]

Hi,
The trouble is that to relax the final status will cause those seeking a
truly immutable class to complain. Its a balance - the previous version did
have DateTime as not final, but had all the methods final instead. This
created a headache in maintaining the code to ensure that each method was
properly protected against changes.

Basically, DateTime is not meant to be a base API, but is meant to be a
fundamental type, like String.

In v0.98 we supplied a full implementation in BaseDateTime in the base
subpackage. Is it possible for you to implement your DateTime class to
extend BaseDateTime?

Or you could write your date time class so it holds a reference to a real
DateTime in an instance variable, delegating methods as appropriate. This is
often the best solution.

BTW, I don't use Hibernate, but I would be surprised if there wasn't some
way to persist final classes, after all it must deal with String and Integer
which are both final.

Also, perhaps you could let us know what convenience methods you added. It
helps build up a picture of methods that we may have missed from DateTime
itself.

Stephen


----- Original Message -----
From: "Tuyen Truong" <tuy...@gm...>
> I use Hibernate to persist the DateTime class. Consequently, the class
> needs to implement UserType and LiteralType. Also, we have some
> convenience methods that we would like to throw in the class itself.
> This is not possible if the class is finalized.
>
> As an alternative, is it possible to finalize the methods in the class
> instead? Since it's a base API, finalizing the class seems too
> restrictive.
>
> Thanks,
>
> Tuyen
>
> On Tue, 23 Nov 2004 18:10:27 +0000, Stephen Colebourne
> <ste...@ho...> wrote:
> > Can you give me any more details on what your abstraction contained?
> >
> > The final is needed to properly secure immutable status. It also makes
the
> > MutableDateTime class much more friendly.
> >
> > If you can give me more info on why you want to subclass I may be able
to
> > help.
> >
> > Thanks
> > Stephen
> >
> > >From: Tuyen Truong <tuy...@gm...>
> >
> >
> > >I am very confused as to why you finalized many of the classes in
> > >version 0.98 (particularly DateTime). I'm guessing it is for
> > >performance reasons, but it is causing a lot of problems for me. We
> > >had created a thin abstraction around DateTime for our use and now it
> > >is no longer possible to subclass it. Are there other reasons why the
> > >class is finalized and could this be removed for the next release?
> > >
> > >Otherwise, great job on the implementation.
> > >
> > >Thanks,
> > >
> > >Tuyen
> >
> >
>