package-accessible clone?

H

Hendrik Maryns

Hello,

I have a compositum of classes which represent a formula. When writing
down formulas, it is usual to define `predicates´: abbreviations for
long formulas, which may contain several free variables, which later
reappear with specific variables filled in.

To implement this, I defined a class FormulaTemplate, which stores a
Formula and an array of Variables. It defines a method
getFormula(Variable... inputVariables), which should return a copy of
the stored formula where the variables at specific places (given at
construction time) are replaced by the supplied variables.

To do this, I want to clone the stored formula (it should be possible to
invoke this method several times with different arguments), replace the
variables where needed and return the clone.

On the other hand, I want formulas to be immutable. All its methods are
inspector methods or return bigger formulas. So it does not make sense
to define a public clone method in Formula.

So I thought: put them in the same package, and make clone() package
accessible, then the Template has acces to it, whereas client classes do
not:

/**
* Creates and returns a copy of this object.
*
* @see java.lang.Object#clone()
*/
@Override
abstract Formula clone();

But now the compiler complains: Cannot reduce the visibility of the
inherited method from Object.

What is a good solution to this problem? Why can´t I declare clone()
package-accessible? Should I define a specific method for this? I
don´t want Formula to implement Cloneable either, as clients should not
know about clone().

Thanks for some comments, H.
--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
 
Z

zero

Hello,

I have a compositum of classes which represent a formula. When
writing down formulas, it is usual to define `predicates´:
abbreviations for long formulas, which may contain several free
variables, which later reappear with specific variables filled in.

To implement this, I defined a class FormulaTemplate, which stores a
Formula and an array of Variables. It defines a method
getFormula(Variable... inputVariables), which should return a copy of
the stored formula where the variables at specific places (given at
construction time) are replaced by the supplied variables.

To do this, I want to clone the stored formula (it should be possible
to invoke this method several times with different arguments), replace
the variables where needed and return the clone.

On the other hand, I want formulas to be immutable. All its methods
are inspector methods or return bigger formulas. So it does not make
sense to define a public clone method in Formula.

So I thought: put them in the same package, and make clone() package
accessible, then the Template has acces to it, whereas client classes
do not:

/**
* Creates and returns a copy of this object.
*
* @see java.lang.Object#clone()
*/
@Override abstract Formula clone();

But now the compiler complains: Cannot reduce the visibility of the
inherited method from Object.

What is a good solution to this problem? Why can´t I declare clone()
package-accessible? Should I define a specific method for this? I
don´t want Formula to implement Cloneable either, as clients should
not know about clone().

Thanks for some comments, H.

How about you just rename the clone method to copy() That way the copy
method can have package access, and the compiler won't complain. This
copy method could just return this.clone(), if that is appropriate for
your design. Object:clone has protected access (which is also why the
compiler complains when you want to make it package access), so that's
consistent with your idea of not making it public. If the design doesn't
call for a protected clone method, just put the cloning code in the copy
method directly.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,071
Latest member
MetabolicSolutionsKeto

Latest Threads

Top