David Bergman writes:
Alexey wrote:
Well, I don't have an ultimate answer, but here's a couple of candidates:
Range Iterator Range View Series Succession
These terms are not synonymous.
I didn't imply they were.
If you knew they were not synonymous, yet you suggest them as name candidates for a specific concept. This gives me an uneasy feeling of (at least your notion of) the concept.
I don't see why. Would you have a problem with putting "Cursor" and "Iterator" on the same list, if you were to name a beast with 'current', 'next' and 'done' methods? They are not synonyms either.
Some imply an ordering, others do not.
Depending on your definition of ordering none or all of them do.
Ordering should be intrinsic not coincidental.
How's that related to my statement?
The standard's "Sequence" concept has a definite ordering,
Doesn't matter what standard's "Sequence" concept has; for one, it's a dead concept. A "sequence" as a word in a programmer's dictionary doesn't imply a definite ordering in the sense in which the term is used in the standard; "random sequence" is a perfect, well, sequence.
neither "Collection" not "Container" imply any ordering.
They all guarantee that the 'end' reachable from 'begin', that is, that by repeatedly incrementing 'begin' you'll go through a range of successive elements until you reach the 'end'. I don't see anything inherent in the word "sequence", or, for that matter, "series" or "succession" that implies more than just that. Again, "random series" or "random succession [of something]".
Those are coincidental orderings. Sequences have an intrinsic ordering, being part of the conceptual structure of the entity.
Since a sequential machine only executes one instruction at a time, ALL structures should then be considered ordered according to you, no?
If every instruction in a program is executed just once, it definitely imposes an order relationship on them.
I mean, it all starts and ends ;-)
My dictionary defines collection as "an accumulated assortment of things of a particular type" - which sounds ok for this concept. There's no implication of containing or owning the things, so the fact that VB (or CS in general) have used the term to describe ownership is a fault in VB, not the word!
Programming is all about communication; it doesn't matter what the original meaning of the word is/was; what matters is what your teammates think of when they hear it. I'm claiming that most people think of collection classes, i.e. containers with storage.
I think on a quite different beast when I hear "sequence" (at least from a senior CS and/or IT individual) than when I hear "collection."
Which was exactly my point. [...]
Does it? Seems like a supporting case to me:
virtual class Collection[T] inherits Any ** insert a T into the collection insert(t:T) : Self[T] is deferred ^^^^^^^^^^^
If that doesn't imply storage, I don't know what does.
Could you not say that about any altering operation? That any altering operation on a notion implies storage?
No. Changing range boundaries doesn't, for instance. But again, I don't see how it's related to my point.
I think you have a far too pragmatic view on these things, which does not rhyme very well with proper (GP) conceptualization.
There Sequence is an ordered Collection, which fits both the STL terms and the proposal for "Collection Traits".
IMHO the example of range_view(0,100) could happily be called a ForwardCollection - there's no containment but there's a definite ordering.
My problem is that Collection _does_ imply storage for me, and the connotation is continuously reinforced by a numerous examples from all around.
I probably agree that this specific concept, Collection, bears a strong storage component,
Great!
but do you consider even proxy structures to have "storage."?
What's a proxy structure? -- Aleksey Gurtovoy MetaCommunications Engineering