Re: Q: making 'bad' Constructors protected/private

From: Andrus Adamchik (
Date: Sun Mar 02 2003 - 11:38:56 EST

  • Next message: Holger Hoffstätte: "SortedList in sandbox/holger"

    Holger Hoffstätte wrote:

    > Not in the cases that I had in mind; it's more an API ease-of-use thing.
    > For example ObjectId has an implicit public constructor, but the resulting
    > instance is useless since the only setter - setIdKeys() - is protected, so
    > the other constructors are the only 'usable' ones.

    I am confused, ObjectId doesn't have a default constructor.

    > Similar Attribute and Relationship. If you construct e.g. an empty
    > DbAttribute and try to add it to a DataMap, it will raise an exception

    In case of DbAttribute, you can always call setName before adding to an
    entity. We use it all over in the unit tests. I don't have any serious
    objections to making it protected (but not private), I just don't see a
    need to do so.

    Oh, and aClass.newInstance() will no longer work (or will it?) :-). Not
    that we use it a lot.


    This archive was generated by hypermail 2.0.0 : Sun Mar 02 2003 - 11:40:24 EST