Re: hierarchy of interface/implementations.
horos11@gmail.com wrote:
yeah, I sort of gathered that you couldn't do this, but I think that
is more a limitation of java [sic] than anything else. You may argue not so
for interfaces, because you can have a class implement many of them
(and hence the 'inheritance' tree is really a bush), but for an
abstract class - or any arbitrary class for that matter - I think it
is a lot clearer to have an inherited class tied to its parent in a
very clear way.
Java packages are namespaces and not hierarchical.
Consider the whole reader design decision in java. I personally think
that
Reader.InputStream
is a lot clearer than
InputStreamReader
because it implicitly shows the relationship between the two classes,
InputStream dose not depend on Reader, though Readers depend on InputStreams.
The notation 'Reader.InputStream' implies that 'InputStream' is nested
within 'Reader', which is not true.
and lends itself to a hierarchy
Packages are not hierarchical.
(like files inside a directory belong to that directory).
Likewise, I'd like to be able to name my class 'File', and hnece say:
You can most certainly name your class 'File'.
Semaphore.File sf = new Semaphore.File()
because I'm using a *type* of Semaphore.
Well, that isn't Java. It also exposes implementation of the Semaphore, which
in OO is a Bad Thing. You're also stealing the syntax of nested classes.
I do admit that an abstract class works better in this case than an interface,
Does it? Why?
but as it is I need
to manually mangle the name to avoid conflict with java's [sic] File class.
No, you don't. Use the fully-qualified names.
Anyways, I don't want to make this a big deal, I'll work with it. It's
not like I have any choice. :)
Sure you do. You can use interfaces to hide implementation details instead of
revealing them. You can use packages as they are designed, as
non-hierarchical namespaces. You can name your class 'File' if you wish. If
Java really doesn't do what you want, you can use a different language.
--
Lew