| AbstractTreeIterator is both Iterator and Collection [message #424092] |
Thu, 16 October 2008 01:23  |
Eclipse User |
|
|
|
AbstractTreeIterator is both iterator and collection, and that is quite
puzzling. I guess there must be a good reason for that, but trying to
understand how a single object can fulfill both contracts at the same time
gives me a headache.
For instance, being foo an AbstractTreeIterator, even if foo.hasNext() is
true, foo.isEmpty() is true too. Also, what should one expect of
foo.iterator()?
Cheers,
Rafael
|
|
|
|
|
| Re: AbstractTreeIterator is both Iterator and Collection [message #424112 is a reply to message #424107] |
Thu, 16 October 2008 12:56  |
| Eclipse User |
|
|
|
Rafael,
Comments below.
Rafael Chaves wrote:
> Ed Merks wrote:
>
>> It is extending list is just an implementation detail. The list
>> manages the stack of iterators that collectively induce an overall
>> iteration over the whole tree. The list could have been stored in a
>> field, but then you'd have one more object. In other words, it's
>> pointless for a client to see anything beyond the TreeIterator
>> interface....
>
> That is unfortunate...
For whom?
> The list of interfaces implemented by an object's class is not an
> implementation detail, instead, it is a public statement of the
> contracts an object complies with.
It's an implementation class. If you surface only the API to the
client, TreeIterator<Foo> that's all the client should concern
themselves with.
>
> Once that object is passed around, how can generic client code tell
> the difference between which interfaces are implemented as contract
> and which ones are an internal implementation detail?
What generic code starts arbitrarily testing for implementations of APIs
of arbitrary objects?
> IOW, client code that does:
>
> if (object instanceof Collection) {
> // treat object as collection
>
> is bound to fail.
It is a perfectly valid collection so what would fail?
>
> My 2 cents...
Where is this relevant though? It seems more a theoretical/manufactured
problem than a practical one, unless I'm missing something... Have a
look at java.sql.TimeStamp for some truly unfortunate design.
>
> Rafael
>
|
|
|
Powered by
FUDForum. Page generated in 0.05374 seconds
Home