Re: Re: DS_CIRCULAR

Brian Heilig:

> But now that I think of it, I like the perspective that a 
> circular is a list that _can also_ be traversed circularly. 

Once you've done that you can also extend it to
say that _all_ lists can be traversed circularly, 
that is:

- all lists are circular from an interface viewpoint
- _some_ lists are circular from an implementation 
  viewpoint

So it would clearly be wrong to have only circular 
implementations inherit from the circular 
abstraction.

So you should have something like

class DS_CIRCULAR 
inherit DS_TRAVERSABLE
feature
 forth ensure not off

class DS_LINEAR 
inherit DS_TRAVERSABLE
feature
 after: BOOLEAN
 forth -- can end up off
 go_after

class DS_LINEAR_CIRCULAR
inherit 
 DS_CIRCULAR rename forth as circular_forth
 DS_LINEAR

And DS_LIST and everybody else inherit from 
DS_LINEAR_CIRCULAR.

Problem with this is that it introduces a nasty case of 
repeated inheritance, and given that circular traversal is 
not really useful, the only practical way to do it would 
be simply add directly circular_forth in DS_LINEAR, or 
new_circular_cursor (and the container cursor 
features remain non circular). It makes circular 
traversal a second rank citizen, but to some 
extent is is, not being the primary way you 
want to iterate on these structures.



To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/gobo-eiffel/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/