Eclipse Community Forums: EMF » AbstractTreeIterator is both Iterator and Collection

Help

Home

Home » Modeling » EMF » AbstractTreeIterator is both Iterator and Collection

Show: Today's Messages :: Show Polls :: Message Navigator

AbstractTreeIterator is both Iterator and Collection [message #424092]

Thu, 16 October 2008 05:23

Rafael Chaves

Messages: 161
Registered: July 2009

Senior Member

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

Report message to a moderator

Re: AbstractTreeIterator is both Iterator and Collection [message #424100 is a reply to message #424092]

Thu, 16 October 2008 14:16

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

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....

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: AbstractTreeIterator is both Iterator and Collection [message #424107 is a reply to message #424100]

Thu, 16 October 2008 15:06

Rafael Chaves

Messages: 161
Registered: July 2009

Senior Member

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... 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.

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? IOW, client code that does:

if (object instanceof Collection) {
// treat object as collection

is bound to fail.

My 2 cents...

Rafael

Report message to a moderator

Re: AbstractTreeIterator is both Iterator and Collection [message #424112 is a reply to message #424107]

Thu, 16 October 2008 16:56

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

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
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	Building UML2-approximated Model in EMF
Next Topic:	EMF Editor fails during opening

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 11:42:24 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter