Re: operator overloading
On Wed, 21 May 2008, Mark Space wrote:
Tom Anderson wrote:
Hmm. What happens if i call get(int) on my three-dimensional matrix?
A slightly more practical implementation would be something like:
public abstract class AbstractMatrix<class T>
{
public T get( int i ) {
throw new UnsupportedOperationException("Not implemented.");
}
public T get( int i, int j ) {
throw new UnsupportedOperationException("Not implemented.");
}
public T get( int ... i ) {
throw new UnsupportedOperationException("Not implemented.");
}
}
This is how AbstractList and the other abstract collections work. Most
methods throw an exception. You override them if you need them,
otherwise you just don't call them.
I expect the mutator methods of an immutable collection to throw
UnsupportedOperationExceptions - that's a little under half. I don't
expect the other methods, or any methods of a mutable collection, to do
so. I'd be surprised and annoyed to have a class that did so.
You're proposing a class where *two thirds* of the methods will always
throw such an exception. Surely this is the design screaming out to us to
be factored into three separate classes?
tom
--
They didn't have any answers - they just wanted weed and entitlement.