Sigh. This is getting very silly. One very last time and then I need to
get on with work.

In message <049a01c4d821$13f7bde0$3fe22641 at antssoftware.com>
          "Joshua Scholar" <jscholar at access4less.net> wrote:

> I didn't say that collections should be copied before iterating over them.
Nor I. I _did_ point out that it had been mentioned - I think perhaps
by Richard O'Keefe as an example of some other langauge's way?

> I specifically said that such copies are too expensive.
Me too. And, as it happens, incorrect as a way of solving the problem.

> 
> I didn't say that collections should be locked while iterating over them, I
> only said that it doesn't make sense to expect iterators to change their
> behavior mid-stream if you try to mutate collection out from under them -
> that this was too much to ask, just like implicit copying was too much to
> ask.
You said "become: affecting an active iteration is wrong.  Iterations
can only be clean if they're over a snapshot not over a live collection
anyway." which seems like requiring a copy of some sort to me.  It
isn't so much that become: affecting things is wrong so much as it just
plain _does_ affect them.

You also said "Since I was only talking about iterating over primitive
types like arrays, it's not possible to change the size of the
collection while iterating over it." which is clearly not correct in
the face of capabilities like become:. We also don't have 'primitive
types' in any sense that could correspond to anything much but perhaps
this was just verbal sugar.

#become: _does_ affect the object in an active context, whether you
like it or not. It can't avoid it - you send one object the message
#become: with an argument of some other object and the identities are
swapped including in the methodcontext in which you are running to send
that message. Can it be confusing? You bet your sweet bippy. Can it be
fatal? Damn right - amongst other things it can cause the very next
bytecode to blow the VM away since and compiler generated offsets into
the receiver it thouhgt it had can be wrong. Can it work 'correctly'?
Sure - how do you think we mutate instances of classes that have their
shape changed?


> Is my writing that hard to understand?
It would appear so. I'm not generally considered particularly stupid
but perhaps senility has suddenly crept up on me.

> Ah well, I try anyway:
[snip]
Thank you for a nice restating of exactly what I've been saying. Which
is almost the same as most of what you have been saying. By the way, did
you come here for the five minute argument or the full half-hour? 

>  Your
> example tells me nothing about become: becaue it isn't proper useage of
> become:.
It doesn't matter whether that particular example is considered 'proper'
by some standard, it simply matters that it is perfectly plausible
Smalltalk that represents a class of things that can and do happen in
real systems.

> 
> If you want to propose redesigns of every iterator to handle these things go
> ahead.  BUT IT'S NOT A FLAW IN MY PROPOSAL THAT IT DOESN'T MAKE THE CODE
> HANDLE CASES THAT IT ALREADY CAN'T HANDLE.
Good grief man, get a grip and stop shouting. I haven't proposed
changing a single thing about iterating, nor do I care to. I happen to
quite like it as it is.

My sole original comments on the idea of some primitive relating to
iterating were
a) that it wouldn't provide much of a speedup, if any in actual
practise, since the meat of the work is the code in the iterator block.
A primitive will not affect said block.
b) I further mused that to use such an iterator primitive for something
like an OrderedCollection would require possibly two passes if the
start/stop indices had wrapped at all.
c) Finally I mused that maybe someone might think it smart to somehow
lock the collection as part of the prim in order to (they think)
prevent any of the problems inherent in code that modifies the
collection and dismissed it as inadequate.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: GLV: Ground the Line Voltage