'Path' implementation

[Lee Salzman]

I committed a small iterator/stream fix that ensures pastEndPut: uses
addLast: on any ExtensibleSequence. Hope this helps.

On Wed, Sep 08, 2004 at 10:17:21AM -0700, Brian T. Rice wrote:
> >The problem seems to come from the fact that collection concatenation on 
> >line 4 creates ExtensibleArray with 'capacity' based on the 'size' of 
> >concatenated arrays, and later line 6 tries to write into non-existent 
> >element of the array.  It can be demostrated like this:
> >
> >Slate 19> addSlot: #a3 valued: (ExtensibleArray newSize: 5).
> >(a1 . Types . a2 . prototypes .
> >    VM . globals . Mixins . a3 .
> >    traits )
> > > a3 size.
> >0
> > > a3 capacity.
> >5
> > > (a3 ; a3) size.
> >0
> > > (a3 ; a3) capacity.
> >0
> >
> >I'm not sure what should be done with these, because looking closer at 
> >ExtensibleArray, I found that I have hard time understanding 
> >capacity/size idioms; newSize: does not set size but capacity instead, 
> >size can be changed only by addFirst:/addLast:/removeFirst:/removeLast:, 
> > at: and at:put: don't care about size at all...  Is this all intentional?
> 
> Nope, in fact this method should be overridden to do the obvious 
> addLast: thing. All of this complexity is just inherited by (my) 
> laziness from Smalltalk's way of doing streams.
> 
> The issue with the capacity/size is also inherited from Smalltalk, 
> although they use new: instead of newSize:, so in this case Slate is 
> slightly confusing. I have been strongly considering merging 
> newEmpty/newSize: into new &capacity: which would alleviate a lot of 
> this but introduce many sends-with-optionals.
> 
> >thanks (mainly for slate, the more I use it the more I like it!), and I 
> >apologize for such a long posting.
> 
> Don't apologize, this is great work in tracking down problems, and of 
> course we're glad that any users are happy. :)