> Let's have a little vote > Do we need support for > a) private no argument constructors?
+1 Here's the reason why i thought it as 'something i need'. With a private constructor I was able to build a it was possible for me to prevent the Domain Object api developers from being able to create the object in an 'invalid' state. So, basically it helped me to create a cleaner domain object api. Thanks Jaideep Ganguli Thomas Mahler wrote: > > hi all, > > Ganguli Jaideep wrote: > > Hi all, > > > > Is it absolutely necessary to have a public no argument constructor for > > my domain objects? > > > > I have worked with another OR Mapping tool before (Toplink) where this > > was not necessary. It still needed a no argument constructor, but the > > constructor wasn't required to be public, it could be private. > > > > The main reason to rely on a public constructor was performance. If > there is no public constructor you'll have to do some additional > reflection magic to make construction possible. > > We wanted to keep things simple, thus we also don't have a feature to > specify factory classes and methods to construct domain objects. > > Let's have a little vote > Do we need support for > a) private no argument constructors? > > b) userdefined factories to build domain objects? > > cheers, > Thomas > > > Thanks > > > > Jaideep > > > > -- > > To unsubscribe, e-mail: <mailto:[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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
