Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2004-05-06 09:35:30


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

> > 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? 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."
 
> > > > | In CS terminology, collections are inherently associated with
> > > > | storage;
> > > >
> > > > can give any examples of this CS terminology?
> > >
> > > http://tinyurl.com/yr3bb
> >
> > I don't think there's a good case for either side of the argument.
> > Several of the sites you give as examples of "Collection" implying
> > storage contradict your point:
> >
> > http://www.cs.man.ac.uk/arch/people/j-sargeant/ufolib/node5.html
>
> 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?

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, but do you consider even proxy structures to have
"storage."?

/David


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk